[systemd-devel] systemd-hostnamed not shutting down when unused

[Lennart Poettering]

On Mon, 07.07.14 09:46, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:

> 
> Hi,
> 
> I have tested it and it is working on git.
> 
> I dug this up to figure few things out on shutting down dbus activated
> services when they are idle. Is it possible that follow up activation
> request on a service is being ignored by systemd because application
> has just recently quit?
> 
> I have this extreme case,
> 
> - Service shuts down
> - Dbus gets a signal up on service shutdown (systemd doesn't get
> SIGCHLD yet) and acknowledges disappearance of the service
> - An activation request comes up on the service
> - Dbus sends a dbus signal to systemd to activate the service
> - Systemd receives the request but is still thinking service is
> active, so ignores the request
> - Systemd receives the SIGCHLD and changes the state of service to inactive.
> 
> This scenario is very unlikely but I am trying to figure out if there
> are other possibilities. Thoughts?

Hmm, interesting issue. Not entirely sure though what the right strategy
could be here...

Something like this could work:

With sd_notify() hostnamed should tell PID 1 when it begins its
shutdown. This should then be reflected in the service state PID 1 keeps
track off. The sd_notify() socket should be processed at a higher
priority than dbus, so that this is always processed first.

With that in place, if dbus then sends an activation request it would be
queued by PID, and be processed as soon as the service stop is
complete, so that the service start is then done immediately after.

Introducing sd_notify() messages that can notify PID 1 about daemons
reloading or shutting down, has been on the TODO list for a while, I
wanted that for mere prettiness, but now it turns out this might
actually fix a race...

I figure this problem will go away with kdbus, as the activation request
stays around until it is processed (because it it is a durable POLLIN on
the activation fd). But then again, being able to tell systemd about
state changes in the daemon is still very useful.

Internally, hostnamed will actually drop the name first, and then
process requests as long as there's still something queued, and only
then terminate. THis doesn't help here, but is supposed to at least fix
the most obvious race, where bus messages might get stuck and dropped in
the socket...

Lennart

-- 
Lennart Poettering, Red Hat