launchctl Bootstrap failed: 5: Input/output error 가 뜰 때: 같은 번호 5 뒤에 숨은 원인들과 load 가 실패해도 종료 코드 0 을 주는 이유When launchctl says Bootstrap failed: 5: Input/output error: the causes hiding behind the same number 5, and why load returns exit code 0 even when it fails
launchctl 에서 Input/output error 를 만난 독자가 같은 문구 뒤의 서로 다른 원인을 명령 몇 개로 가르고, load 대신 bootstrap 을 쓰는 이유와 올라간 뒤 상태를 확인하는 법을 알게 돕는다.
시험에서 번호 5 는 이미 올라간 job 다시 올리기, 없는 파일, 깨진 plist, Label 이나 실행 항목이 없는 plist, 같은 Label 의 다른 파일, disable 된 Label, world-writable 파일에서 똑같이 나왔고 문구로는 구분되지 않았다. 옛 load·unload 는 같은 실패에도 종료 코드 0 을 주었고 bootstrap·bootout 은 5 를 주었다. 없는 프로그램을 가리킨 plist 는 오류 없이 올라가 상태 78 로 남았다.
오류가 나면 plutil -lint 와 launchctl print gui/$(id -u)/라벨 로 파일과 현재 상태를 보고, 스크립트에서는 load 대신 bootout 후 bootstrap 을 쓰며 올라간 뒤에도 last exit code 를 확인하라.
목차
한 줄 요약:
Bootstrap failed: 5는 원인을 말해 주지 않는 번호라 상태를 직접 봐야 하고, 옛launchctl load는 같은 실패에도 종료 코드 0 을 준다.
$ launchctl bootstrap gui/501 ~/Library/LaunchAgents/com.example.job.plist
Bootstrap failed: 5: Input/output error
Try re-running the command as root for richer errors.(오류 문구는 시험 출력에서 가져왔고 파일 이름은 예시다.)
이 글은 같은 문구가 어떤 서로 다른 상황에서 나오는지, 어느 명령으로 가르는지, 그리고 load 계열이 실패를 어떻게 숨기는지를 macOS 26.6.2(arm64)에서 직접 돌려 확인한 결과다(2026-11-11). 시험은 com.example.shlab.* 라는 임시 Label 만 썼고 시험 전체를 두 번 실행해 출력(프로세스 번호와 임시 폴더 이름 제외)이 같았다. 공개된 질문도 Catalina 부터 Sonoma 까지 여러 버전에서 같은 문구를 보고하고 있어(Apple 개발자 포럼 665661, 774570 등, 검색 결과 제목과 요약만 확인했고 본문은 열지 못했다) 문구만으로는 원인을 알 수 없다.
용어 먼저. launchd 는 맥에서 백그라운드 작업(job)을 띄우는 시스템 서비스이고, launchctl 은 거기에 job 을 올리고 내리는 명령이다. job 은 plist 파일에 Label(이름)과 실행할 프로그램을 적어 정의한다. 도메인은 job 이 올라가는 자리이고, 내 계정으로 로그인한 상태의 도메인이 gui/501 처럼 쓰는 gui/사용자번호(내 번호는 id -u)다.
같은 5번 뒤에 있는 원인들
아래는 모두 launchctl bootstrap gui/501 파일.plist 로 올린 결과다. 이미 올라간 상태를 시험한 줄은 표에 그렇게 적었다.
| 상황 | 결과 | 종료 코드 |
|---|---|---|
| 정상 파일을 처음 올림 | 출력 없음, 올라감 | 0 |
| 이미 올라간 같은 파일을 다시 올림 | Bootstrap failed: 5: Input/output error |
5 |
| 없는 파일 경로 | 같은 문구 | 5 |
끝이 잘린 plist(plutil -lint 는 Encountered unexpected EOF) |
같은 문구 | 5 |
문법은 맞지만 Label 이 없음(plutil -lint 는 OK) |
같은 문구 | 5 |
문법은 맞지만 ProgramArguments·Program 이 없음(plutil -lint 는 OK) |
같은 문구 | 5 |
| 이미 올라간 Label 과 같은 Label 을 가진 다른 파일 | 같은 문구 | 5 |
launchctl disable 해 둔 Label |
같은 문구 | 5 |
| 파일 권한 666(누구나 쓰기) | 같은 문구 | 5 |
system 도메인에 일반 사용자로 올림 |
같은 문구 | 5 |
원인의 갈래는 이미 올라감, 파일 없음·깨짐, 필수 키 없음, 중복 Label, disable, 쓰기 권한, 도메인이고 문구는 전부 같다. 그래서 오류 문구를 검색해 나온 처방 하나를 따라 해도 자기 원인이 아니면 그대로 실패한다. 공개 검색 결과의 요약에 나온 처방도 disable 해제, unload 후 다시 load, plist 점검 등으로 갈린다(요약만 보았고 각 글의 답변은 열지 못했다). 이 글이 직접 확인한 것은 위 표의 갈래들이 같은 문구를 낸다는 것이다.
반대로 문구가 다른 경우도 있었다. 없는 사용자 번호로 올리면(gui/9999) Could not find domain for user gui: 9999(종료 코드 112)였고, 올라가지 않은 Label 을 launchctl print gui/501/없는이름 으로 보면 Could not find service … in domain for user gui: 501(종료 코드 113)이었다. 이미 내려간 Label 을 launchctl bootout gui/501/라벨 로 또 내리면 5 가 아니라 Boot-out failed: 3: No such process(종료 코드 3)였다.
가르는 순서
원인이 문구에 없으니 상태를 직접 본다. 단계마다 걸러 내는 갈래가 다르고, 이 글의 시험에서 단계별 출력을 확인한 것은 아래에 적었다.
plutil -lint 파일.plist— 문법이 깨진 파일을 걸러 낸다.Encountered unexpected EOF같은 말이 나온다. 단OK가 나와도Label이나 실행 항목이 빠진 파일은 통과한다./usr/libexec/PlistBuddy -c 'Print :Label' 파일.plist와-c 'Print :ProgramArguments' 파일.plist—Label과 실행 항목이 있는지 본다. 시험에서ProgramArguments가 없는 파일은Print: Entry, ":ProgramArguments", Does Not Exist(종료 코드 1), 있는 파일은 배열을 출력했다. (Program키를 쓰는 plist 라면Print :Program도 본다. 이 키는 별도로 시험하지 않았다.)launchctl print gui/$(id -u)/라벨— 이미 올라가 있으면 경로(path = …)와 상태가 나오고, 없으면 종료 코드 113 이다. 올라가 있는데path가 내가 올리려던 파일이 아니라면 중복 Label 일 수 있다(이path출력은 위 시험 기록에 따로 남기지 않았다).launchctl print-disabled gui/$(id -u)— disable 된 Label 을 걸러 낸다. 시험에서launchctl disable뒤에는"라벨" => disabled,launchctl enable뒤에는"라벨" => enabled가 나왔고, disable 된 Label 의bootstrap은 5 로 실패했다가 enable 뒤 올라갔다.ls -l 파일.plist— 누구나 쓰기(666)가 켜져 있는지 본다.- 명령의 도메인이
gui/$(id -u)인지 본다.system도메인에 일반 사용자로 올린 것은 같은 5 였고 위 1~5 단계가 이 갈래를 가려 주지는 않으니, 문구가 같을 때 도메인 인자부터 의심하는 수밖에 없다. 사용자 번호가 틀리면 112 로 문구가 달라진다.
권한은 설명서와 달랐다(시험은 bootstrap 으로만 했다). man launchctl 의 load 항목은 설정 파일이 “그룹과 전체의 쓰기를 허용하지 않아야 한다” 고 적는데, 같은 파일을 권한만 바꿔 사용자 도메인에 올렸더니 600·644·664 는 모두 올라갔고 666 만 5 로 실패했다. 그룹 쓰기(664)를 막지 않는다는 뜻이 아니라 이 시험 환경(내 폴더, 내 소유 파일, 사용자 도메인)에서 그렇게 나왔다는 것이다. root 소유 파일이나 /Library 아래는 시험하지 않았다.
같은 실패를 load 는 종료 코드 0 으로 말한다
(이 절의 “같은 실패” 는 위 표에서 시험한 5번 계열 실패에 한정한다.)
인터넷의 오래된 안내는 launchctl load ~/Library/LaunchAgents/…plist 를 쓰고, man launchctl 은 이것을 “LEGACY SUBCOMMANDS” 로 분류하며 bootstrap·bootout·enable·disable 을 대안으로 적는다. 같은 파일에 같은 실패를 만들어 두 명령을 비교했다.
| 상황 | load·unload |
bootstrap·bootout |
|---|---|---|
| 이미 올라간 파일 다시 올림 | Load failed: 5, 종료 코드 0 |
Bootstrap failed: 5, 종료 코드 5 |
| 없는 파일 | Load failed: 5, 종료 코드 0 |
종료 코드 5 |
| 깨진 plist | Load failed: 5, 종료 코드 0 |
종료 코드 5 |
| disable 된 Label | Load failed: 5, 종료 코드 0 |
종료 코드 5 |
| 이미 내려간 파일을 또 내림 | Unload failed: 5, 종료 코드 0 |
파일 경로로 내리면 5, Label 로 내리면 3 |
load 도 같은 번호 5 를 찍지만 종료 코드가 0 이다. 그래서 스크립트에서 launchctl load x.plist || exit 1 은 종료 코드가 0 이니 못 잡는다(이 줄 자체를 돌린 것이 아니라 위 종료 코드에서 이어진 결론이다). set -e 를 켠 셸에서도 깨진 파일에 load 를 한 다음 줄이 그대로 실행됐고 종료 코드는 0 이었다. 같은 줄을 bootstrap 으로 바꾸면 종료 코드 5 로 멈췄다. 오류 문구를 2>/dev/null 로 버려 둔 설치 스크립트라면 job 이 안 올라간 것을 아무도 모른 채 “설치 완료” 가 출력될 수 있다.
올라가고도 일을 못 하는 경우
5 가 안 나왔다고 끝이 아니다. 아래 세 가지 plist 는 오류 없이 올라갔고(종료 코드 0), 1초 뒤 launchctl list 의 상태 칸이 78 이었다. 마지막 두 줄은 대조용이다.
| plist 가 가리킨 프로그램 | launchctl list |
launchctl print |
|---|---|---|
| 없는 경로 | pid -, 상태 78 |
last exit code = 78: EX_CONFIG |
있지만 실행 권한(chmod +x)이 없는 스크립트 |
pid -, 상태 78 |
last exit code 같음 |
홈에 실제로 있는 실행 가능한 스크립트를 ~/shlab-job.sh 로 가리킴 |
pid -, 상태 78 |
last exit code 같음 |
같은 스크립트를 /Users/…/shlab-job.sh 절대 경로로 가리킴 |
pid -, 상태 0 |
last exit code = 0 |
| 임시 폴더의 정상 스크립트(대조) | pid -, 상태 0 |
last exit code = 0 |
launchctl list 에서 가운데 숫자(상태)가 이 세 사례처럼 78 이면 job 은 올라갔어도 실행에 실패한 것이다. 0 이 아닌 다른 값은 프로그램이 낸 종료 코드일 수 있어 이 글에서 시험하지 않았다. ~ 사례는 같은 파일을 절대 경로로 바꾸면 0 이 되어 경로 표기가 원인이었다. 왜 풀리지 않는지는 plist 의 ProgramArguments 를 셸이 아니라 launchd 가 직접 읽기 때문으로 보이는데, 이것은 이 글의 해석이고 launchd 내부를 확인한 것은 아니다. launchctl print 는 78 에 EX_CONFIG 라는 이름을 붙여 적는다(sysexits.h 의 설정 오류 코드 이름이다). 이 글은 이 세 가지만 시험했고 프로그램이 실행된 뒤의 실패, StandardErrorPath 로그, KeepAlive 재시작은 다루지 않았다.
다시 올리는 함수
설치 스크립트가 할 일은 “이미 올라가 있으면 내렸다 올리고, 올라갔는지 확인하는 것” 이다. 시험에 쓴 함수와 같은 내용이다(시험 스크립트에서는 U 가 전역 변수이고 여기서는 지역 변수로 선언했다는 점만 다르다).
reload() {
local plist=$1 label U="gui/$(id -u)"
plutil -lint "$plist" >/dev/null || { echo "plist 문법 오류"; return 2; }
label=$(/usr/libexec/PlistBuddy -c 'Print :Label' "$plist" 2>/dev/null) || { echo "Label 없음"; return 2; }
launchctl bootout "$U/$label" 2>/dev/null
launchctl bootstrap "$U" "$plist" 2>/dev/null || { echo "bootstrap 실패: $label"; return 1; }
launchctl print "$U/$label" >/dev/null 2>&1 || { echo "올라가지 않음: $label"; return 1; }
echo "올라감: $label"
}같은 파일에 두 번 연속 호출했을 때 둘 다 종료 코드 0 이었다(bootout 이 먼저 내려서 이미 올라감 실패가 안 났다). 깨진 파일과 Label 없는 파일은 2, ProgramArguments 없는 파일과 disable 된 Label 은 1 이었고 enable 뒤에는 0 이었다. 이 함수가 못 잡는 것도 있다. 없는 프로그램을 가리킨 plist 는 올라감 으로 나오고 종료 코드 0 이다. 그건 1초쯤 기다린 뒤 launchctl print 의 last exit code 를 읽어야 보인다. launchctl 의 새 하위 명령 출력은 형식이 안정적이라고 약속되지 않았다고 man launchctl 이 적고 있으니, last exit code 를 읽는 이 방법도 지금 버전 기준임을 알아 두면 된다.
오류를 만났을 때 확인 순서와 시험 범위
- 위 가르는 순서 1~6 을 차례로 본다. 특히
launchctl print gui/$(id -u)/라벨이 이미 올라가 있다고 답하면 문제는 파일이 아니라 중복 올리기이니bootout후 다시 올린다. - 스크립트라면
load를bootstrap·bootout으로 바꾸고 종료 코드를 본다.bootout은 올라가 있지 않은 Label(올렸다 내린 것과 한 번도 올린 적 없는 것 모두 시험했다)에서도 종료 코드 3 을 주니 재설치 스크립트에서는 그 코드를 무시한다. - 올라간 뒤에는 1초쯤 뒤
launchctl list | grep 라벨의 상태 칸이 0 인지 본다. - 시험 환경: macOS 26.6.2(arm64), 사용자 도메인
gui/501, 내 소유 파일, bash 3.2.57 에서의 명령 실행. root 로system도메인을 쓰는 경우(LaunchDaemons),/Library/LaunchAgents, 앱이 번들에 넣은 서비스(SMAppService)와 샌드박스 앱, 다른 macOS 버전,launchctl bootstrap을 root 로 다시 쳤을 때 “richer errors” 가 실제로 나오는지는 시험하지 않았다.
세 줄 요약
Bootstrap failed: 5는 이미 올라감·없는 파일·깨진 plist·Label누락·중복·disable·666 권한에서 똑같이 나오니plutil -lint·launchctl print로 상태를 본다.- 옛
launchctl load·unload는 같은 실패에도 종료 코드 0 을 주므로|| exit이나set -e가 실패를 못 잡고,bootstrap·bootout은 5(또는 3)를 준다. - 오류 없이 올라간 job 도 프로그램 경로가 없거나 실행 권한이 없거나
~/로 적으면 상태 78 로 남으니 올린 뒤launchctl list의 상태 칸을 확인한다.
To help a reader who met Input/output error in launchctl tell the different causes behind the same text with a few commands, and learn why to use bootstrap instead of load and how to check the state after loading.
In my tests the number 5 came out identically for loading a job that was already loaded, a missing file, a broken plist, a plist without a Label or a program entry, a different file with the same Label, a disabled Label and a world-writable file, and the text alone did not tell them apart. The old load and unload gave exit code 0 for the same failures, while bootstrap and bootout gave 5. A plist pointing at a missing program loaded without an error and was left with status 78.
When the error appears, look at the file and the current state with plutil -lint and launchctl print gui/$(id -u)/label. In scripts, use bootout and then bootstrap instead of load, and check last exit code even after the job loads.
Contents
One-line summary:
Bootstrap failed: 5is a number that does not name the cause, so you have to look at the state yourself, and the oldlaunchctl loadgives exit code 0 for the same failure.
$ launchctl bootstrap gui/501 ~/Library/LaunchAgents/com.example.job.plist
Bootstrap failed: 5: Input/output error
Try re-running the command as root for richer errors.(The error text is taken from the test output and the file name is an example.)
This post shows, from commands I ran myself on macOS 26.6.2 (arm64) on 2026-11-11, which different situations produce this same text, which command tells them apart, and how the load family hides failures. The tests used only temporary Labels named com.example.shlab.*, and I ran the whole set twice; the output (apart from process numbers and temporary folder names) was identical. Public questions also report the same text on several versions from Catalina to Sonoma (Apple Developer Forums 665661, 774570 and others; I checked only the search result titles and summaries and could not open the bodies), so the text alone cannot tell you the cause.
Terms first. launchd is the macOS system service that starts background jobs, and launchctl is the command that loads and unloads jobs there. A job is defined in a plist file with a Label (its name) and the program to run. A domain is the place a job is loaded into; the domain for your own logged-in account is written gui/<user number>, such as gui/501 (your number is id -u).
The causes behind the same 5
Everything below was loaded with launchctl bootstrap gui/501 file.plist. Rows that test the already-loaded state are marked as such in the table.
| Situation | Result | Exit code |
|---|---|---|
| Loading a normal file for the first time | No output, loaded | 0 |
| Loading the same already loaded file again | Bootstrap failed: 5: Input/output error |
5 |
| A file path that does not exist | Same text | 5 |
A truncated plist (plutil -lint says Encountered unexpected EOF) |
Same text | 5 |
Valid syntax but no Label (plutil -lint says OK) |
Same text | 5 |
Valid syntax but no ProgramArguments or Program (plutil -lint says OK) |
Same text | 5 |
| A different file with the same Label as one already loaded | Same text | 5 |
A Label that was launchctl disabled |
Same text | 5 |
| File permissions 666 (writable by anyone) | Same text | 5 |
Loading into the system domain as a normal user |
Same text | 5 |
The groups of causes are already loaded, file missing or broken, required key missing, duplicate Label, disable, write permission and domain, and the text is the same for all of them. So if you search for the error text and follow one remedy you find, it fails just the same when it is not your cause. The remedies in the public search-result summaries also split into lifting a disable, unloading and loading again, checking the plist and so on (I saw only the summaries and could not open each answer). What I confirmed myself is that the branches in the table above produce the same text.
There were also cases where the text differed. Loading for a user number that does not exist (gui/9999) gave Could not find domain for user gui: 9999 (exit code 112), and looking at a Label that is not loaded with launchctl print gui/501/no-such-name gave Could not find service … in domain for user gui: 501 (exit code 113). Unloading an already unloaded Label again with launchctl bootout gui/501/label gave not 5 but Boot-out failed: 3: No such process (exit code 3).
The order for telling them apart
The cause is not in the text, so look at the state directly. Each step filters out different branches, and what I confirmed in the tests is written below.
plutil -lint file.plist— filters out a file whose syntax is broken. It prints something likeEncountered unexpected EOF. But a file missingLabelor the program entry still passes withOK./usr/libexec/PlistBuddy -c 'Print :Label' file.plistand-c 'Print :ProgramArguments' file.plist— check whetherLabeland the program entry exist. In the tests, a file withoutProgramArgumentsprintedPrint: Entry, ":ProgramArguments", Does Not Exist(exit code 1) and a file with it printed the array. (If the plist uses theProgramkey, also look atPrint :Program; I did not test that key separately.)launchctl print gui/$(id -u)/label— if it is already loaded, it prints the path (path = …) and the state; if not, the exit code is 113. If it is loaded andpathis not the file you meant to load, the Label may be duplicated (I did not keep thispathoutput in the test record above).launchctl print-disabled gui/$(id -u)— filters out a disabled Label. In the tests, afterlaunchctl disableit printed"label" => disabledand afterlaunchctl enableit printed"label" => enabled, andbootstrapof the disabled Label failed with 5 and then loaded afterenable.ls -l file.plist— check whether world-write (666) is on.- Check that the domain in the command is
gui/$(id -u). Loading into thesystemdomain as a normal user gave the same 5, and steps 1 to 5 above do not tell that branch apart, so when the text is the same the only thing to do is to suspect the domain argument first. A wrong user number changes the text to 112.
Permissions differed from the manual (I tested only with bootstrap). The load entry of man launchctl says configuration files must “disallow group and world writes”, but when I changed only the permissions of the same file and loaded it into the user domain, 600, 644 and 664 all loaded and only 666 failed with 5. That does not mean group write (664) is never blocked; it is what came out in this test setup (my folder, my own file, the user domain). I did not test root-owned files or anything under /Library.
load reports the same failure with exit code 0
(“The same failure” in this section is limited to the number-5 failures tested in the table above.)
Old guides on the internet use launchctl load ~/Library/LaunchAgents/….plist, and man launchctl files it under “LEGACY SUBCOMMANDS” and lists bootstrap, bootout, enable and disable as the alternatives. I made the same failures on the same files and compared the two commands.
| Situation | load, unload |
bootstrap, bootout |
|---|---|---|
| Loading an already loaded file again | Load failed: 5, exit code 0 |
Bootstrap failed: 5, exit code 5 |
| A file that does not exist | Load failed: 5, exit code 0 |
exit code 5 |
| A broken plist | Load failed: 5, exit code 0 |
exit code 5 |
| A disabled Label | Load failed: 5, exit code 0 |
exit code 5 |
| Unloading an already unloaded file again | Unload failed: 5, exit code 0 |
5 by file path, 3 by Label |
load prints the same number 5 but its exit code is 0. So in a script, launchctl load x.plist || exit 1 does not catch it, since the exit code is 0 (this is a conclusion from the exit codes above; I did not run that exact line). Even in a shell with set -e, the line after a load of a broken file ran and the exit code was 0. Changing the same line to bootstrap stopped it with exit code 5. An install script that discards the error text with 2>/dev/null can print “install complete” while nobody knows the job never loaded.
Jobs that load and still do no work
Not seeing a 5 is not the end. The three plists below loaded without an error (exit code 0), and one second later the status column of launchctl list was 78. The last two rows are for comparison.
| Program the plist pointed to | launchctl list |
launchctl print |
|---|---|---|
| A path that does not exist | pid -, status 78 |
last exit code = 78: EX_CONFIG |
A script that exists but has no execute permission (chmod +x) |
pid -, status 78 |
last exit code the same |
An executable script that really exists in the home folder, pointed to as ~/shlab-job.sh |
pid -, status 78 |
last exit code the same |
The same script pointed to by the absolute path /Users/…/shlab-job.sh |
pid -, status 0 |
last exit code = 0 |
| A normal script in a temporary folder (for comparison) | pid -, status 0 |
last exit code = 0 |
If the middle number (status) in launchctl list is 78 as in these three cases, the job loaded but failed to run. Other non-zero values may be exit codes the program itself returned, which I did not test. The ~ case became 0 when I switched the same file to its absolute path, so the path notation was the cause. Why it is not expanded appears to be that ProgramArguments in a plist is read by launchd directly and not by a shell, but that is this post’s interpretation and I did not check launchd’s internals. launchctl print attaches the name EX_CONFIG to 78 (the name of a configuration-error code in sysexits.h). I tested only these three, and did not cover failures after the program has started, StandardErrorPath logs, or KeepAlive restarts.
A function that reloads
What an install script needs is “if it is already loaded, unload and load again, then check that it loaded”. This is the same as the function used in the tests (the only difference is that in the test script U is a global variable and here it is declared local).
reload() {
local plist=$1 label U="gui/$(id -u)"
plutil -lint "$plist" >/dev/null || { echo "plist syntax error"; return 2; }
label=$(/usr/libexec/PlistBuddy -c 'Print :Label' "$plist" 2>/dev/null) || { echo "no Label"; return 2; }
launchctl bootout "$U/$label" 2>/dev/null
launchctl bootstrap "$U" "$plist" 2>/dev/null || { echo "bootstrap failed: $label"; return 1; }
launchctl print "$U/$label" >/dev/null 2>&1 || { echo "not loaded: $label"; return 1; }
echo "loaded: $label"
}Called twice in a row on the same file, both exit codes were 0 (bootout unloads first, so the already-loaded failure does not occur). A broken file and a file without Label gave 2, and a file without ProgramArguments and a disabled Label gave 1, which became 0 after enable. There is something this function cannot catch. A plist pointing at a missing program prints loaded with exit code 0. That only shows up if you wait about a second and read last exit code from launchctl print. man launchctl says the output of the newer subcommands is not promised to keep a stable format, so keep in mind that this way of reading last exit code holds for the current version.
Order for checking when you hit the error, and the scope of the tests
- Go through steps 1 to 6 of the order above. In particular, if
launchctl print gui/$(id -u)/labelsays it is already loaded, the problem is not the file but loading twice, sobootoutand load again. - In a script, replace
loadwithbootstrapandbootoutand look at the exit codes.bootoutalso gives exit code 3 for a Label that is not loaded (I tested both one that was loaded and then unloaded and one never loaded), so a reinstall script should ignore that code. - After loading, about a second later, check that the status column of
launchctl list | grep labelis 0. - Test environment: macOS 26.6.2 (arm64), the user domain
gui/501, my own files, commands run from bash 3.2.57. I did not test root with thesystemdomain (LaunchDaemons),/Library/LaunchAgents, services an app bundles (SMAppService) and sandboxed apps, other macOS versions, or whether “richer errors” actually appear whenlaunchctl bootstrapis run again as root.
Three-line summary
Bootstrap failed: 5comes out the same for already loaded, a missing file, a broken plist, a missing or duplicateLabel, disable and 666 permissions, so check the state withplutil -lintandlaunchctl print.- The old
launchctl loadandunloadgive exit code 0 for the same failures, so|| exitandset -edo not catch them, whilebootstrapandbootoutgive 5 (or 3). - A job that loaded without an error still stays at status 78 if its program path is missing, lacks execute permission or is written starting with
~/, so check the status column oflaunchctl listafter loading.