[systemd-devel] systemd --user sometimes is not stopped by systemd-exit.service
Lennart Poettering
lennart at poettering.net
Mon Sep 30 19:34:36 PDT 2013
On Thu, 26.09.13 09:41, Andrey Borzenkov (arvidjaar at gmail.com) wrote:
> I'm still observing timeouts stopping user at 0.service on shutdown. It
> appears to be some race condition, because enabling debugging of either
> main systemd or user systemd, or even changing console from vt to
> serial would hide it. Sometimes it also works using vt console as well.
>
> Here is difference between good case and bad case.
Hmm, if you patch systemd to generate a message when RTMAX-6 is received
(and only then, leaving debug mode off), do you see this message
generated? i.e. I'd really like to know whether the shutdown signal
tthat is sent from the user systemd's systemd-exit.service to the user
systemd process is actually received...
> - /* Run the exit target if there is one, if not, just exit. */
> - if (manager_start_target(m, SPECIAL_EXIT_TARGET, JOB_REPLACE) < 0) {
> - m->exit_code = MANAGER_EXIT;
> - return 0;
> - }
> + /* Run the exit target and exit. */
> + manager_start_target(m, SPECIAL_EXIT_TARGET, JOB_REPLACE);
> + m->exit_code = MANAGER_EXIT;
> + return 0;
>
> break;
>
>
> We obviously assume that SIGTERM/SIGINT always stop user instance
> anyway. This just makes it obvious (and removes need to send additional
> signal).
>
> Still I wonder if anyone has idea about this race condition and how to
> debug it (so far any attempt would eliminate race).
Race condition? Which one?
The workaround patch is nothing we can merge. We need the ability for
people to install user units that are invoked before the session goes
down, i.e. units that are ordered against exit.target and
systemd-exit.service... This is the whole reason we do this indirection
via signal sending at all...
Lennart
--
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel
mailing list