Service not working on Macos 14.4.1 (23E224)

[distante]

I have been running autokbisw for a while now and was working succesfully, but after some weeks the background service does not seem to start.

If I manually /opt/homebrew/opt/autokbisw/bin/autokbisw -v 2 it works as expected

But without it, it does not do anything.

I reinstalled everything, I removed and readded autokbisw to the Input Monitoring allow apps but it does not work.

I am on the latest brew version 1.4.3

Any idea what could be happening?

Thanks!

[ohueter]

Moving this to Discussions as it's not an autokbisw issue.

Could you post the output of brew services?

[distante]

Hi thank you for your reply. This is the output:

❯ brew services
Name      Status  User   File
autokbisw started distante ~/Library/LaunchAgents/homebrew.mxcl.autokbisw.plist
unbound   none

homebrew.mxcl.autokbisw.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>KeepAlive</key>
	<true/>
	<key>Label</key>
	<string>homebrew.mxcl.autokbisw</string>
	<key>LimitLoadToSessionType</key>
	<array>
		<string>Aqua</string>
		<string>Background</string>
		<string>LoginWindow</string>
		<string>StandardIO</string>
		<string>System</string>
	</array>
	<key>ProgramArguments</key>
	<array>
		<string>/opt/homebrew/opt/autokbisw/bin/autokbisw</string>
	</array>
	<key>RunAtLoad</key>
	<true/>
	<key>StandardErrorPath</key>
	<string>/opt/homebrew/var/log/autokbisw.log</string>
	<key>StandardOutPath</key>
	<string>/opt/homebrew/var/log/autokbisw.log</string>
</dict>
</plist>

/opt/homebrew/var/log/autokbisw.log is empty.

[ohueter]

This looks as expected which is good.

Is /opt/homebrew/opt/autokbisw/bin/autokbisw (with this exact path) added at System Preferences > Security & Privacy > Privacy > Input Monitoring?

Does ps aux | grep autokbisw show more than one running instance of the program?

[distante]

Actually, it is not added in that way but with /opt/homebrew/Cellar/autokbisw/1.4.3/bin but opt/homebrew/opt/autobrisk is a symlink to /opt/homebrew/Cellar/autokbisw/1.4.3

ps aux | grep autokbisw shows two entries:

❯ ps aux | grep autokbisw
distante           16647   0.0  0.0 411345168   9360   ??  S     2:34PM   0:00.09 /opt/homebrew/opt/autokbisw/bin/autokbisw
distante          93588   0.0  0.0 410732240   1392 s003  S+   10:36AM   0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox autokbisw

[ohueter]

Thats fine, both are the same on my system. Are you running any other software that messes with keyboard input, like Karabiner-Elements, or the Automatically switch to a document's input source system setting enabled?

You could try to enable logging by editing ~/Library/LaunchAgents/homebrew.mxcl.autokbisw.plist and adding the -v 2 argument (restart the service afterwards). I don't remember the exact syntax, something like

<array>
  <string>/opt/homebrew/opt/autokbisw/bin/autokbisw</string>
  <string>-v</string>
  <string>2</string>
</array>

but I'm not sure about this. Then, the /opt/homebrew/var/log/autokbisw.log should be populated.

[distante]

I am not using Karabiner or anything similar, also Automatically switch to a document's input source is disabled

Interesting enough, after adding the -v 2 in the plist and reboot, it works.

I will remove them and check what happened.

I also, before reboot, did this:

launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.autokbisw.plist
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.autokbisw.plist

[distante]

So it removed the log, unload and loaded the plist and rebooted.

It still works.

Maybe the plist was somehow corrupted and unload and load helped?

[ohueter]

I'm glad you found a way to solve your issue! This also makes great documentation for future issues, thanks for the detailed postings!

I remember having all sort of weird issues with launchctl services in the past. Maybe it needed to reload the plist file because an internal reference got lost or something. We'll never know :)