On Thu, 26.09.13 09:41, Andrey Borzenkov (arvidj...@gmail.com) wrote:
> I'm still observing timeouts stopping user@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.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
