On Wednesday, January 4, 2017 08:16 CET, Antoine Jacoutot <ajacou...@bsdfrog.org> wrote:
> On Tue, Jan 03, 2017 at 11:01:18PM -0700, Andy Bradford wrote: > > Hello, > > > > Since I couldn't find any reference to this anywhere, I thought I would > > put out a description of the problem in the event that someone else runs > > into it with other daemons. > > > > At one point in time, identd -l had a different meaning than it does > > now. After upgrading, I noticed that identd was not running, thanks to > > the following section in the daily output email: > > > > Services that should be running but aren't: > > identd > > > > So I began investigating why it wasn't running and found the following > > in /var/log/messages: > > > > Jan 3 22:46:56 obsd identd[80696]: h/auth: no address associated with name > > Jan 3 22:46:56 obsd identd[84721]: child has gone > > > > Looking at the output, it seemed clear that something had changed, so I > > looked at the man page for identd, and sure enough, -l is now different. > > Previously, in /etc/rc.conf.local, I had: > > > > identd_flags="-elh" > > > > Which coincided with the error message. Clearly -lh meant that it was > > trying to look up a host named h, which doesn't exist, whereas before, > > -l meant to log to syslog. So, I removed the -l from identd_flags, and > > tried to restart the daemon. Much to my dismay, it failed to restart, > > even though I had corrected the problem in rc.conf.local. > > > > As it turns out, after further investigation, I discovered that the > > flags get cached in /var/run/rc.d/identd: > > > > $ cat /var/run/rc.d/identd > > daemon_class=daemon > > daemon_flags=-elh > > daemon_rtable=0 > > daemon_timeout=30 > > daemon_user=root > > pexp=identd: (listen|resolver) > > > > There's the offending -l that I thought I had removed! > > > > I can see why now: > > > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr?annotate=1.116 > > > > On line 109, the options that are cached in the _RC_RUNFILE override any > > that were provided before rc_cmd() was called. > > > > Not sure if this is a bug. How often does a command line option get > > repurposed for something else? > > > > At any rate, I wanted to give a heads up to anyone else who might end up > > with a daemon which refuses to restart, even after the options have been > > corrected. > > Nice catch, but the real issue comes from identd(8). > > # /usr/sbin/identd -elh > # echo $? > 0 > # pgrep identd > # > > See, it's not running but the return code was 0 which made rc.d(8) believed the > daemon was properly started in which case the variable are cached (so that we > can still match the daemon in the process list if the flags are changed in > rc.conf.local). > > Someone fix identd please :-) I've also hit this in the past with other daemons from ports, i.e. logstash as an example. It starts up, and backgrounds, and then later, it parses its argument, figures it got a wrong parameter and exits. Then trying to add debug parameter to rc.conf.local, and see it not taking the debug parameter into account, because the cached values from /var/run/rc.d/... are used. It caused me a bit of head scratching before I found these cached values there. I guess there might be other daemons that might expose such behaviour as well. Wondering why the cached parameters take precedence? Sebastian > > -- > Antoine
