This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Siddhesh Poyarekar <siddhesh@redhat.com> writes:

> Russ, thank you for your very detailed explanation!

Happy to (hopefully) help!  All the details of this are in the top of my
mind at the moment for some reason....

> nscd does not care what the child process does; it simply forks and
> exits.

Yeah, this is the most common way of implementing the forking model.  It
means that the readiness protocol isn't really correct, since often the
child isn't actually ready to accept connections at the time of the fork,
but that won't matter with socket activation.

> The PID file is created after parsing options and configuration, so
> service can still fail after that due to other reasons, like a corrupt
> database, failure to start its worker threads, etc. and not actually be
> ready.  It shouldn't be too difficult to delay the PID file creation to
> a point where nscd considers itself ready.

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.

> All other options seem like a lot more additional work and I am not
> convinced that nscd deserves that kind of love right now.  Also, trying
> to make nscd a notify type service seems like hard-coding it for nscd
> and I am not convinced about it, given that there's an alternative that
> serves the purpose.

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.

The sd_notify(3) protocol uses an environment variable to signal whether
to do startup notification and skips the notification if that variable
isn't set, so a service that supports Type=notify can still be used in the
other ways with no negative effects.  The notification will just be
skipped.  Of course, nscd still has to have that code, and in the glibc
context that probably means open-coding the sd_notify call in the nscd
source, which is not horribly attractive.  (But the shared library
dependency issues are probably even worse.)

-- 
Russ Allbery (eagle@eyrie.org)              <http://www.eyrie.org/~eagle/>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]