systemctl on Mac: Stop and Disable Left My Job Running

I gave a test job on the Mac mini that runs this business a KeepAlive key, then did what a Linux hand would do to shut it down for good: launchctl disable, then launchctl kill TERM. Twelve seconds later it was running again with a new PID. Both commands had exited 0. Without KeepAlive, disable on its own didn't stop the job either, and launchctl kickstart -k happily started the disabled job again.

There is no systemctl on macOS. Typing it gets you zsh: command not found: systemctl. Homebrew does carry a systemd formula, but its formula file says depends_on :linux and ships bottles only for Linux. (On this Mac, brew install --dry-run systemd still answered "Would install 1 formula", so don't take that as a yes.) The tool you use instead is launchctl. The verbs line up only roughly, and where they don't, nothing warns you. "systemctl mac" gets 73 Google autocomplete completions, led by "systemctl equivalent in mac". Below is each common systemctl verb mapped to the launchctl command that actually does the job, with the exit codes I got on macOS 26.4.1, and a small shell function that wraps them.

The systemctl to launchctl table

Everything here targets a per-user LaunchAgent, which lives in ~/Library/LaunchAgents and runs in the gui/<uid> domain. For a system daemon, swap in system/ and add sudo. The difference between the two is covered in LaunchAgent vs LaunchDaemon. In the table, $D is gui/$(id -u) and $L is the job's Label.

systemctl	launchctl on macOS 26	What differs
start	launchctl kickstart $D/$L	The job must already be loaded (bootstrapped), or you get exit 113
stop	launchctl bootout $D/$L	This also unloads it. kill is the gentler option, but a KeepAlive job comes back
restart	launchctl kickstart -k $D/$L	Keeps the old program arguments even if you edited the plist
daemon-reload	bootout then bootstrap $D path.plist	Done per job. There's no global reload
enable / disable	launchctl enable|disable $D/$L	Disable only blocks the next load. It doesn't stop the running job
status	launchctl print $D/$L	Exit 0 even when the job isn't running. Exit 113 if it isn't loaded
list-units	launchctl list	Columns are PID, last exit status, Label. A negative status means it died from a signal
journalctl -u	log show --predicate 'eventMessage CONTAINS "$L"'	Shows launchd lifecycle lines only. Program output goes to StandardOutPath

Older answers use launchctl load, unload, start and stop. They still run, but the man page on this machine lists them under LEGACY SUBCOMMANDS, which work out the target domain from whether you're root, so the same command can hit a different domain under sudo. The newer verbs take the domain explicitly.

What I measured, row by row

The test job was a LaunchAgent with the label cc.picklog.probe.systemctl whose program echoes a timestamp and then sleeps for 600 seconds. Each step below ran on a Mac mini M4 (Mac16,10) as a normal user, and I read the job's state from launchctl print after each one.

$ launchctl print gui/501/cc.picklog.probe.systemctl
Bad request.
Could not find service "cc.picklog.probe.systemctl" in domain for user gui: 501
exit=113
$ launchctl bootstrap gui/501 /tmp/sysctl-lab/cc.picklog.probe.systemctl.plist
exit=0                       # state = not running (no RunAtLoad)
$ launchctl kickstart gui/501/cc.picklog.probe.systemctl
exit=0                       # state = running, runs = 1
$ launchctl disable gui/501/cc.picklog.probe.systemctl
exit=0                       # state = running, still
$ launchctl kickstart -k gui/501/cc.picklog.probe.systemctl
exit=0                       # runs = 4, while disabled
$ launchctl kill TERM gui/501/cc.picklog.probe.systemctl
exit=0                       # state = not running, still loaded
$ launchctl kill TERM gui/501/cc.picklog.probe.systemctl
No process to signal.
exit=3

disable is not stop. That part matches Linux: the systemctl man page says disable "does not implicitly stop the units". What surprised me is that kickstart ignores the flag too. Apple's man page explains it: kickstart runs the service "regardless of its configured launch conditions", and disable only means the service "cannot be loaded" until you enable it again. So disable works at load time. A job that's already loaded keeps running until you boot it out.

restart doesn't re-read the plist. I changed the echo string in the plist and ran kickstart -k. The new process printed the old string, and launchctl print still listed the old arguments. launchd works from the copy it read at bootstrap time. To pick up an edit, boot the job out and bootstrap it again. That's the per-job equivalent of systemctl daemon-reload, and it's also how you change environment variables, which I ran into separately in launchctl setenv not working.

One error message, two causes. Running bootstrap on a disabled job and on a job that's already loaded printed the same thing:

Bootstrap failed: 5: Input/output error
Try re-running the command as root for richer errors.
exit=5

Neither problem has anything to do with I/O or root. The other common causes of this error are in launchctl load failed: 5: Input/output error. When I hit it, I check launchctl print first (is the job already loaded?), then launchctl print-disabled gui/501 | grep label.

Why stop has to be bootout

With KeepAlive set to true, kill TERM put the job in state = spawn scheduled, and launchd started it again 8 seconds later. Disable first and then kill: same thing, back up with runs = 3. The only command that kept it down was launchctl bootout.

Homebrew came to the same conclusion. In Homebrew's services code, brew services start copies the plist into ~/Library/LaunchAgents, runs launchctl enable, then launchctl bootstrap. brew services stop runs launchctl bootout. On Linux the same file calls systemctl enable, stop and daemon-reload. So if what you actually typed was "mac systemctl start docker" or "systemctl start postgresql", the nearest thing on a Mac is brew services start postgresql. For anything you wrote yourself, use launchctl directly.

bootout has a cost: once the job is unloaded, launchctl print can't find it, so you lose the last exit code that systemctl status would still show for a stopped unit. If you need that number, read it before booting the job out. launchctl print last exit status covers where that field is and what it misses.

This machine has 26 plists in ~/Library/LaunchAgents. 18 of them run on StartCalendarInterval, the closest thing to a systemd timer, and 3 use KeepAlive. One of the calendar jobs fires the ten daily slots that publish this blog, and its print output showed runs = 64 and last exit code = 0 when I checked. If you're choosing between launchd and cron, I compared them in launchd vs cron.

What the top answers say

I pulled every question with "systemctl" in the title from Stack Overflow, Super User, Ask Different, Unix & Linux, Server Fault and Ask Ubuntu through the Stack Exchange API, and kept the ones about macOS. That left 4 questions with 357,667 views and 5 answers between them. The accepted answer on the biggest one (Stack Overflow 47934081, 238,743 views, 187 votes) is one sentence saying the equivalent is launchctl, plus a link to the man page. The Unix & Linux answer says there is no port. Only one answer, on Ask Different 364094, gives any verb beyond list.

To see which verbs people are actually told to use, I took the 20 top-voted questions with "launchctl" in the title from each of Stack Overflow, Ask Different and Super User: 60 questions, 1,034,025 views, 144 answers. 43 of those answers name a launchctl verb. 23 of the 43 use only the legacy ones. load shows up in 21 answers, bootstrap in 9, bootout in 3, and kickstart, the actual restart command, in 2.

A systemctl-style function for LaunchAgents

This is the wrapper I tested. It covers the eight verbs above for jobs in your own GUI domain. SCTL_DIR lets you point it at a plist folder other than ~/Library/LaunchAgents.

# systemctl-style verbs for per-user LaunchAgents (macOS launchd)
sctl() {
  local verb=$1 label=$2
  local d="gui/$(id -u)"
  local p="${SCTL_DIR:-$HOME/Library/LaunchAgents}/$label.plist"
  case $verb in
    start)     launchctl print "$d/$label" >/dev/null 2>&1 || launchctl bootstrap "$d" "$p" || return
               launchctl kickstart "$d/$label" ;;
    stop)      launchctl bootout "$d/$label" ;;
    restart)   launchctl kickstart -k "$d/$label" ;;
    reload)    launchctl bootout "$d/$label" 2>/dev/null
               launchctl bootstrap "$d" "$p" ;;
    enable)    launchctl enable "$d/$label" ;;
    disable)   launchctl disable "$d/$label" ;;
    status)    launchctl print "$d/$label" | grep -E '^[[:space:]](state|pid|runs|last exit code) =' ;;
    is-active) launchctl print "$d/$label" 2>/dev/null | grep -q '^[[:space:]]state = running' ;;
    *) echo "usage: sctl {start|stop|restart|reload|enable|disable|status|is-active} <label>" >&2
       return 2 ;;
  esac
}

$ sctl is-active cc.picklog.probe.systemctl; echo $?
1
$ sctl start cc.picklog.probe.systemctl && sctl status cc.picklog.probe.systemctl
	state = xpcproxy
	runs = 1
	pid = 15699
	last exit code = (never exited)
$ sctl stop cc.picklog.probe.systemctl; sctl is-active cc.picklog.probe.systemctl; echo $?
1

It gave the same results under zsh -f, /bin/bash 3.2 and /bin/sh. Two limits. reload reloads the plist but doesn't start the job unless the plist has RunAtLoad, which is also how daemon-reload behaves. And as the transcript shows, straight after start the state can read xpcproxy, not running, because launchd is still spawning the process. An is-active check run in that same instant says no.

For the log side, the predicate in the table turned up 20 launchd lines for the test job over 10 minutes. Disable and enable events even name the process chain that asked for them, like initiated by launchctl[9572]<-zsh[9406]. Anything the program printed went to its StandardOutPath file and nowhere else. More filters are in the log show command on Mac.

FAQ

Is there a systemctl command on Mac?

No. macOS uses launchd as its service manager, and you control it with launchctl. systemd depends on Linux kernel features, and Homebrew's systemd formula is marked Linux-only. For services installed through Homebrew, brew services start|stop|restart is the closest thing, and it calls launchctl under the hood.

How do I restart a service on macOS?

Run launchctl kickstart -k gui/$(id -u)/LABEL for a user agent, or sudo launchctl kickstart -k system/LABEL for a system daemon. It kills the running instance and starts a new one. It won't pick up edits to the plist, though. For that, run launchctl bootout and then launchctl bootstrap with the plist path.

Why does my launchd service start again after I stop it?

The plist probably sets KeepAlive. launchd then restarts the job after launchctl kill or the legacy launchctl stop. On macOS 26.4.1 a KeepAlive job came back about 9 seconds after a kill, even after launchctl disable. launchctl bootout gui/$(id -u)/LABEL unloads the job, and that keeps it stopped.

Method: every launchctl command ran on 2026-10-04 between about 16:33 and 16:40 KST on a Mac mini M4 (Mac16,10, macOS 26.4.1 build 25E253, launchd "Darwin Bootstrapper 7.0.0") as a normal user, against a throwaway LaunchAgent in /tmp that was booted out afterwards. I did not test system daemons with sudo, macOS 15 or earlier, or socket-activated jobs. The Homebrew behavior comes from reading Library/Homebrew/services/cli.rb in Homebrew 7.0.7 (repository HEAD 2026-09-28). The answer counts come from the Stack Exchange API that day: the systemctl set is every title match on six sites filtered to macOS, and the launchctl set is the 20 top-voted title matches per site. A regex picked out "launchctl VERB" in each answer body, so it misses a verb written without the word launchctl in front of it. The autocomplete count is from this blog's demand.py run on the same day.