You can do it yourself, in which case you need to unload the MacPorts-supplied wrapper. But IMO, where daemondo is unnecessary, a plist without it should be supplied in MacPorts, so that it has the right name for port load / port unload to work, and so that one doesn't have to replace the plist with one of the same name (which would get clobbered on an update of the port).
For that reason, I have my alternate plist under a different name, so that I just have to keep the MacPort-supplied one disabled. Here's what I have on an older system - I haven't tested it recently or on something newer, nor am I volunteering anything other than information, which may or may not be all wrong. sh-3.2$ cat /Library/LaunchDaemons/local.rsyncd.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>Disabled</key> <true/> <key>Label</key> <string>local.rsyncd</string> <key>Program</key> <string>/opt/local/bin/rsync</string> <key>ProgramArguments</key> <array> <string>/opt/local/bin/rsync</string> <string>--daemon</string> </array> <key>inetdCompatibility</key> <dict> <key>Wait</key> <false/> </dict> <key>Sockets</key> <dict> <key>Listeners</key> <dict> <key>SockServiceName</key> <string>rsync</string> <key>SockType</key> <string>stream</string> </dict> </dict> </dict> </plist> After putting the file in place, one would have to e.g. sudo launchctl unload -w /Library/LaunchDaemons/org.macports.rsyncd.plist sudo launchctl load -w /Library/LaunchDaemons/local.rsyncd.plist > On Oct 25, 2018, at 11:08, Kevin Layer <la...@franz.com> wrote: > > Richard L. Hamilton wrote: > >>> I've had issues before with the whole daemondo wrapper bit. Some >>> things may need it, given how launchd has different expectations >>> from other system's approaches to starting daemons, and some >>> daemons may not have a sufficiently compliant behavior without >>> daemondo as an intermediary. But when it's not actually needed, >>> it's one more thing to go wrong. In the case of rsync as a daemon, >>> it should be possible to write a LaunchDaemon plist file suitable >>> for daemons that could be launched by inetd (on other systems) in >>> nowait mode. > > Is this a problem on the macports side that needs to be addressed, or > do I need to do this myself? If the latter, any pointers? > >>> >>>> On Oct 25, 2018, at 10:00, Kevin Layer <la...@franz.com> wrote: >>>> >>>> Rainer Müller wrote: >>>> >>>>>> On 2018-10-24 16:51, Kevin Layer wrote: >>>>>>> When I installed rsync, I executed the command that was suggested by >>>>>>> the port command. I forget what it was. >>>>>> >>>>>> Probably that was the usual 'sudo port load rsync'. >>>> >>>> That was it. >>>> >>>>>> >>>>>>> After a reboot, every 30 seconds, I see this in /var/log/system.log: >>>>>>> >>>>>>> com.apple.xpc.launchd[1] (org.macports.rsyncd[1044]): Service exited >>>>>>> with abnormal code: 2 >>>>>> >>>>>> That means the rsyncd process exited with an error. You need to look at >>>>>> the error messages to find out why. >>>>>> >>>>>> Try this command to capture the output: >>>>>> sudo launchctl debug system/org.macports.rsync --stdout --stderr >>>>>> >>>>>> Rainer >>>> >>>> Found this in the console: >>>> >>>> 2018-10-25 06:55:16.072468 -0700 default 06:55:16.072468 -0700 rsync >>>> unable to bind any inbound sockets on port 873 >>>> >>>> >>>> And >>>> >>>> # ps ax | grep rsync >>>> 21693 ?? Ss 0:00.00 /opt/local/bin/rsync --daemon >>>> --config=/opt/local/etc/rsyncd.conf >>>> 23272 ?? Ss 0:00.01 /opt/local/bin/daemondo --label=rsyncd >>>> --start-cmd >>>> /opt/local/etc/LaunchDaemons/org.macports.rsyncd/rsyncd.wrapper start ; >>>> --stop-cmd /opt/local/etc/LaunchDaemons/org.macports.rsyncd/rsyncd.wrapper >>>> stop ; --restart-cmd >>>> /opt/local/etc/LaunchDaemons/org.macports.rsyncd/rsyncd.wrapper restart ; >>>> --pid=fileauto --pidfile /opt/local/var/run/rsyncd.pid >>>> # >>>> >>>> >>>> Is the first one supposed to be running, or should daemondo start it >>>> when needed? >>>> >>>> I'm wondering if that's why the port is already in use. >>>> >>>> Thanks. >>>> >>>> Kevin >>>> >
