On 2 Jan 2018, at 13:01 (-0500), Dave Horsfall wrote:
I keep seeing things like the below in my system.log, and it's
annoying:
Jan 3 04:47:43 ozzie com.apple.xpc.launchd[1]
(org.macports.lighttpd): Service only ran for 0 seconds. Pushing
respawn out by 10 seconds.
Jan 3 04:47:44 ozzie com.apple.xpc.launchd[1] (org.macports.ntp):
Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
Most likely these are because the MacPorts software is trying to bind a
listener socket on a port that is already in use. Launchd hates that.
I don't recall installing "lighttpd" (whatever that is),
It's a web server. Having it installed and enabled without recollection
is an oddity. It's not so odd for a Mac to be running Apache (httpd)
which is installed as part of the system and in past versions (through
Lion?) could be turned on or off in the System Preferences. If Apache is
enabled and listening on port 80, starting lighttpd with a default
config will fail.
but I use "ntpd" to sync with my FreeBSD server which will shortly be
GPS-locked; the default Apple servers are on the other side of the
world, and I'm a bit of a locavore.
Yes, and if you have Apple's ntpd running (on by default, in the System
Preferences Date & Time pane) it will prevent a MacPorts installation of
ntpd from running.
What do I need to do to shut 'em up?
As root (i.e. use sudo if you don't have root enabled):
launchctl unload -w org.macports.lighttpd
launchctl unload -w org.macports.ntpd
If you actually want either of them to run, find out what's blocking
them and fix that. Most likely it is Apple's httpd and ntpd, which would
be disabled by:
launchctl unload -w org.apache.httpd
launchctl unload -w org.ntp.ntpd
Then launchd would be able to start the MacPorts daemons and stop
whining into the log.
Note that my knowledge of "launchd" (some sort of a replacement for
/etc/inetd?) is limited to knowing how to spell it...
No, more like a replacement for init (technically a replacement for
SystemStarter, which was Apple's first MacOS X replacement for init)
plus inetd, as well as an alternative to crond. It is what Linux systemd
should have been: a unified supervisor and scheduler that doesn't rely
on a bunch of shell scripts of diverse quality.
--
Bill Cole
[email protected] or [email protected]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
