cannot get real hostname when launching shell script at boot with launchd - macos

I'm trying to run a shell script at boot with launchd, via a plist file in /Library/LaunchDaemons (on 10.8.x, if that matters):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>testD</string>
<key>ProgramArguments</key>
<array>
<string>/Users/lfriedman/cuda-stuff/sw/gpgpu/build/scripts/testing/testD.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
<key>UserName</key>
<string>lfriedman</string>
<key>AbandonProcessGroup</key>
<false/>
<key>StandardOutPath</key>
<string>/tmp/testD.out</string>
<key>StandardErrorPath</key>
<string>/tmp/testD.err</string>
</dict>
</plist>
Inside the shell script is a call to 'hostname -s'. If I run the script manually, everything works fine. If I run the script via cron, everything works fine. However, when it runs at boot via launchd the value returned from 'hostname -s' is always (erroneously) returned as 'localhost', rather than the actual hostname of the system. If I tweak the plist to run the script at a time other than at bootup, it also does the right thing and returns the actual short hostname of the system. This leads me to think that there's some sort of race condition going on where launchd is firing off its jobs before the network subsystem of the OS is fully running.
Is there some special way to ensure that the OS is "fully" booted before launchd runs a job? Or a way to force a delay inside the plist file before the program is invoked?

Unfortunately, launchd doesn't have a way of setting dependencies, so you'll need to have the delay in your script. In a shell script, an easy way to check for networking is:
#!/bin/bash
# Example Daemon Starter
. /etc/rc.common
CheckForNetwork
while [ "${NETWORKUP}" != "-YES-" ]
do
sleep 5
NETWORKUP=
CheckForNetwork
done
# Now do what you need to do.
You can see more info at the following link:
http://blog.slaunchaman.com/2010/07/01/how-to-run-a-launchdaemon-that-requires-networking/

Related

Using launchd to activate daemon on file owner change

I'm trying to get a "daemon" (really just a script, more than a background process) to activate when a file (specifically, /dev/console) changes owner (i.e., when another user takes control of the console) on MacOS Mojave.
I'm trying to do this by running launchd and having it watch that file for changes. I tried doing this with WatchPaths, as in the script below, but apparently that only notices "creating, removing and writing to this file", not chown. Script is below, along with more background story. Any ideas on how to do this?
<?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>Label</key>
<string>LoginScripts.blockyoutube.sh</string>
<key>ProgramArguments</key>
<array>
<string>/Users/Shared/blockyoutube.sh</string>
</array>
<key>WatchPaths</key>
<array>
<string>/dev/console</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StandardOutPath</key>
<string>/var/log/blockyoutube.log</string>
<key>StandardErrorPath</key>
<string>/var/log/blockyoutube.log</string>
</dict>
</plist>
Backstory
What I'm really trying to do is block my kids' accounts from YouTube ... but not my wife's account on the same computer. In theory System Preferences->Parental Controls should do this fine — which it does ... until someone launches Chrome and it backchannels the DNS lookup to 8.8.8.8.
The only way I've figured out to work around this is to not let the OS DNS query fail, so Chrome doesn't attempt to do that, so I'm updating /etc/hosts to point to localhost and flushing DNS whenever the console owner changes. Other solutions to this backstory are also welcome, but it does seem that there should be a way to make launchd watch for change in owner of a file.

Trying to understand launchd daemon state

I am trying to setup a launchd daemon for Zabbix agent on macOS 10.13 High Sierra.
First I install the Zabbix agent with:
brew install zabbix --without-server-proxy
Then I create a property list named com.zabbix.zabbix_agentd.plist with this content:
<?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>AbandonProcessGroup</key>
<true/>
<key>GroupName</key>
<string>zabbix</string>
<key>KeepAlive</key>
<dict>
<key>SuccessfulExit</key>
<false/>
</dict>
<key>Label</key>
<string>com.zabbix.zabbix_agentd</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/sbin/zabbix_agentd</string>
<string>-c</string>
<string>/opt/zabbix/zabbix_agentd.conf</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StandardErrorPath</key>
<string>/var/log/zabbix/zabbix_agentd.error.log</string>
<key>StandardOutPath</key>
<string>/var/log/zabbix/zabbix_agentd.stdout.log</string>
<key>UserName</key>
<string>zabbix</string>
</dict>
</plist>
I load it with:
sudo launchctl load ./com.zabbix.zabbix_agentd.plist
Now I can see that the daemon has done what I expected it to with:
ps ax | grep zabbix_agentd | grep -v grep
I see 6 zabbix processes. 1 collector, 3 listeners, 1 active check and the process that the launch daemon started:
8931 ?? S 0:00.01 /usr/local/sbin/zabbix_agentd -c /opt/zabbix_agentd.conf
But when I run this command:
launchctl print system/com.zabbix.zabbix_agentd | grep state
I get this output:
state = waiting
I expected to see state = running... Why does that command tell me that the daemon is waiting when it has 6 running processes?
Is this "works as designed" or did I do something wrong?
This is sort of "works as designed", but I'd really say it's a result of a philosophical conflict between zabbix and launchd about how daemons should work.
When you run zabbix_agentd, it "daemonizes" itself, meaning that it fires off the actual daemon process as a background subprocess, and then the parent process exits; from that point on, the daemon process (and any subprocesses it starts) run pretty much independently from whatever started them. This is pretty much the traditional way unix daemons operate.
launchd, on the other hand, is written to expect the daemons it manages to stay in the foreground and execute directly under it; this gives launchd much more ability to monitor and control its daemons than it would have if they distanced itself from launchd.
This is a common conflict between traditional unix daemons and launchd, and there are two ways to solve it: either get the daemon to run in the foreground (i.e. conform to the launchd way of doing things), or tell launchd not to worry that the daemon seems to have quit. zabbix_agentd doesn't seem to have anything like a --nodaemon option (according to these docs), so you have to adapt launchd (update: newer versions do, see below). The standard way of doing this, which is pretty much what you have in your .plist, is to add AbandonProcessGroup and KeepAlive keys to tell launchd not to panic when (as far as it can tell) the daemon exits. This works, but it means that launchd cannot tell what's actually going on with the daemon, leading to the weird-looking results you see.
UPDATE: I was looking at an old version of zabbix_agentd. Stefan spotted that a -f (or --foreground) option was added to zabbix_agentd in version 3.0. With this, I'd recommend adding --foreground to the ProgramArguments array, replacing the KeepAlive dictionary with a simple <true/> (this tells launchd to auto-restart the daemon if it exits for any reason), and removing <key>AbandonProcessGroup</key><true/> (this option controls whether launchd cleans up leftover subprocesses if the main daemon process exits/crashes). The result should look something like this:
<?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>GroupName</key>
<string>zabbix</string>
<key>Label</key>
<string>com.zabbix.zabbix_agentd</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/sbin/zabbix_agentd</string>
<string>-c</string>
<string>/opt/zabbix/zabbix_agentd.conf</string>
<string>--foreground</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
<key>StandardErrorPath</key>
<string>/var/log/zabbix/zabbix_agentd.error.log</string>
<key>StandardOutPath</key>
<string>/var/log/zabbix/zabbix_agentd.stdout.log</string>
<key>UserName</key>
<string>zabbix</string>
</dict>
</plist>

launchd does not 'keep alive' processes in El Capitan

I'm trying to make sure a process is always running, even after it quits, crashes or stops in anyway. It's a small binary that reads a serial line and writes to a database - nothing too complex. If it fails to read, it quits with exitcode 70 and it captures any SIGKILL or SIGTERM events and shuts down it's database connections gracefully before actually quitting.
However, the process does NOT launch at load (even though this flag is set), nor does it restart if it is killed. Here is the 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>Disabled</key>
<false/>
<key>KeepAlive</key>
<true/>
<key>Label</key>
<string>blah.bloop.tag05</string>
<key>ProgramArguments</key>
<array>
<string>/Users/blah/Desktop/rfid</string>
<string>-f/dev/tty.usbserial-FT32X30YBXB</string>
<string>-n5</string>
<string>-ctcp://127.0.01</string>
<string>-v</string>
<string>-x100000</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StandardErrorPath</key>
<string>/var/log/rfid.log</string>
<key>StandardOutPath</key>
<string>/var/log/rfid.log</string>
<key>WorkingDirectory</key>
<string>/Users/blah/Desktop</string>
</dict>
</plist>
This plist lives in ~/Library/LaunchAgents (and the user in question can stop and start this process easily enough).
Any thoughts at all? I know there are other processes that are being restarted but I can't for the life of me figure out this one. I thought permissions might be it but these all seem fine :/
I decided to try another plist to see if it was my daemon program at fault. Turns out, it's launchd:
So I decided to run a quick test, using the program tail. I wanted to see if it was my daemon process itself or something to do with launchd. It seems that launchd is the problem. Here is an alternative and simple 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>test.test</string>
<key>ProgramArguments</key>
<array>
<string>/usr/bin/tail</string>
<string>-f</string>
<string>/var/log/system.log</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StandardErrorPath</key>
<string>/tmp/test.test.err</string>
<key>StandardOutPath</key>
<string>/tmp/test.test.out</string>
</dict>
</plist>
I launch this process using the following command
launchctl load test.plist
launchctl start test.test
I then kill the process from another terminal by sending either SIGKILL or SIGTERM to the process with the kill command. Launchd fails to restart the process.
I suspect there must be something new in El-Capitan that I've missed?
Further experimentation has revealed an answer. It appears that only Daemons, such as 'Global Daemons' respect the restart and RunAtLaunch directives. I notice that there are a couple of plists in /Library/LaunchDaemons such as these for TeamViewer and other third party programs.
Interestingly, one can send SIGKILL to processes belonging to Apple such as ImageCaptureAgent and the KeepAlive directive is NOT respected. This is an Apple defined agent plist file that explicitly states a process should be restarted if it is killed, but it does not.
I wonder if Apple changed this functionality in the newer release?

Mac OSX LaunchDaemon on Startup, Shell Script with SSH

I'm hoping someone can help me with this. I've been working on it literally all day...
I want a LaunchDaemon to execute a shell script at startup. Here is my plist file, located at /Library/LaunchDaemons/com.mhi.backup.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>Label</key>
<string>com.mhi.backup</string>
<key>UserName</key>
<string>Joel</string>
<key>GroupName</key>
<string>Admin</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/mhi_websites_backup.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
It executes correctly when I load it from the terminal (launchctl load /Library/LaunchDaemons/com.mhi.backup.plist), but not on startup.
Here is my script, for reference:
#!/bin/bash
sleep 15 #delay script to ensure time for network connection
ssh user#hostname << HERE
mysqldump -u <user_name> -pPASSWORD --all-databases | lzma > alldatabases.sql.lzma
tar cfa backup-`date '+M%mD%dY%y'`.tar.lzma webapps alldatabases.sql.lzma
exit
HERE
scp user#hostname:backup-`date '+M%mD%dY%y'`.tar.lzma /Users/Joel/Desktop
Could someone please help?
Thanks so much,
JG
What errors are you seeing? I would expect that you may have a PATH problem here. Where is mysqldump? If it's in /usr/local/bin, then you probably want to make that explicit, or set the default path in /etc/launchd.conf.
Is the plist owned by root? If a plist in /Library/Launch{Agents,Daemons}/ is not owned by root, it can be loaded with launchctl without sudo, but it is not loaded at login.
You could also try moving the plist to /Library/LaunchAgents/ and adding a LimitLoadToSessionType key:
<key>LimitLoadToSessionType</key>
<array>
<string>LoginWindow</string>
<string>Aqua</string>
</array>
See the Daemons and Agents tech note.

perl script run from inside launchd failing with "No such file or directory" for 'system' commands

I've got a perl script (which is actually run successfully on Linux & Windows as well) that I'm trying to run via launchd on OSX-10.8.3. I'm fairly inexperienced in writing plist files, so I'm hoping this is something silly that I've overlooked. I should note that it runs fine via cron on OSX, so the problems that I'm encountering are specific to launchd. However, when I attempt to run it via launchd, its erroring out on some perl 'system' calls, claiming "No such file or directory". Here's the plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>launched.sysinv</string>
<key>ProgramArguments</key>
<array>
<string>/usr/bin/perl</string>
<string>/Users/lfriedman/cuda-stuff/sw/gpgpu/build/scripts/testing/sysinv.pl</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>14</integer>
<key>Minute</key>
<integer>30</integer>
</dict>
<key>UserName</key>
<string>lfriedman</string>
<key>AbandonProcessGroup</key>
<true/>
<key>StandardOutPath</key>
<string>/tmp/sysinv.out</string>
<key>StandardErrorPath</key>
<string>/tmp/sysinv.err</string>
</dict>
</plist>
When I load the script with "launchctl load -w launchd.sysinv.plist", I see the following error in /var/log/system.log:
com.apple.launchd[1] (launched.sysinv[51676]): Exited with code: 1
/tmp/sysinv.out has the following output with each invocation:
system(/usr/sbin/system_profiler -detailLevel full &> system_profiler.txt) failed: No such file or directory
/tmp/sysinv.err has a single error (with each invocation):
sh: system_profiler.txt: Permission denied
I'm confused what is causing those errors. Again, running the perl script manually (as the 'lfriedman' user) or via a cronjob (owned by 'lfriedman') works fine, with no errors.
When you run the script via plist, the system call is writing its output (system_profiler.txt) to a directory it does not have permissions to write to. When you run it manually or cron, it writes to a directory that has the appropriate permissions.
Edit the script to point the output to a directory you have permissions for, e.g. /usr/sbin/system_profiler -detailLevel full &> /tmp/system_profiler.txt

Resources