[PATCH 4/4] Mark nscd service as forking in systemd service file (#16639)

[Siddhesh Poyarekar]

On Wed, Feb 26, 2014 at 07:39:51PM -0800, Russ Allbery wrote:
> Unfortunately, I didn't check before I wrote up all that about PID files.
> When I investigated further, the systemd documentation seems to indicate
> that the PID file is only used to ensure systemd knows the main process of
> a group of forked processes, and is not used for the notification protocol
> with Type=forking.  Instead, the service is treated as ready (and
> systemctl will then exit successfully) as soon as the parent process
> exits.

The difference between fork point and pid file write is a couple of
operations, like changing the current directory to '/' and creating a
new session.  Unfortunately, neither can be moved to post-fork, so
we're probably back to the readiness protocol being broken for
forking.

> I agree that there's probably nothing particularly wrong with just letting
> nscd be forking.  However, I'm not sure if it will fix the bug.  It will
> only do so if nscd checks the things that the user wanted checked before
> it forks.  If it does so after it forks, you'll see the same behavior with
> a forking service that you do now with simple.

Yeah, AFAICT this is never going to be completely fixed without either
making the nscd daemon 'notify' or 'simple'; the former solution I
personally dislike and the latter probably not possible for nscd.

The other option would be to clearly specify what error conditions
nscd checks before declaring itself as 'active'.  In the current case
with forking mode, it only supports checking for configuration
correctness, i.e. that the command line parameters and the
configuration is correct.  Do we live with that or do we try to make
nscd more 'robust'?

Siddhesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20140227/e43a6dd9/attachment.sig>