RE: "opendkim dead but subsys locked" yet there are opendkim processes

From: Scott Kitterman <ietf-dkim_at_kitterman.com>
Date: Sat, 19 Jan 2013 11:54:23 -0500

Tracy Wise <tracywise_at_hotmail.com> wrote:

>There was actually an error message logged by opendkim in maillog when
>I would start the opendkim service:
>
>
>
>can't write pid to /var/run/opendkim/opendkim.pid: No such file or
>directory
>
>OpenDKIM Filter v2.7.4 starting (args: -x /etc/opendkim.conf -P
>/var/run/opendkim/opendkim.pid)
>
>
>
>
>So apparently the shell script couldn't write the pid file to the
>/var/run/opendkim directory because the directory didn't exist.  The
>cookbook instructions that I followed (on another site, not from your
>docs) set /var/run/opendkim/opendkim.pid as the pid file in
>opendkim.conf yet it didn't instruct me to create that directory (a
>simple but very important step).  
>
>So I just now created the directory and now after starting the service
>it recognizes it when I do "service opendkim status" because it was
>able to create the pid file.
>
>So the problem was all on my end, as usual.
>
>Maybe there is nothing to fix in the shell script; at least there is an
>error message logged.  However, apparently the opendkim daemon returns
>a 0 (true) value even though it wasn't able to create the pid file, and
>hence the subsys lock file is created.  (So that's where the system
>gets confused, because opendkim gets started and lock file created even
>though it wasn't able to create a pid file.)  I don't know if that's
>something to change or not, like I said at least the error message is
>logged (which I should have looked for and noticed from the beginning
>and saved me and you a lot of time).  Or maybe the daemon shouldn't
>return 0 (true) if it can't create the pid file, and simply fail to
>start with the error message logged.  
>
>This is also why I couldn't do "service opendkim stop", simply because
>there was no pid file created when the service started, so the system
>can't find a process id for the service, to stop the process.
>
>I think I'm now all good to go.

The init script that is starting the service should check if the directory exists and create it if it doesn't. /var/run can be on a tempfs so just because you manually created once, it's not guaranteed to always be there.

I would file a bug about this.

Scott K
Received on Sat Jan 19 2013 - 16:54:37 PST