[systemd-bugs] [Bug 77416] systemctl poweroff/reboot does not bring down user services respectfully

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sun Apr 20 04:03:20 PDT 2014


https://bugs.freedesktop.org/show_bug.cgi?id=77416

--- Comment #1 from vimregisters at gmail.com ---
I went and studied some units in /usr/lib/systemd/system so I can get a better
idea of how things are supposed to be done. I saw a pattern, so I mimicked it
with good results.

For example, network.target will pull in a bunch of things as dependencies, but
each one of those units will also contain a "Before=network.target" directive,
to make sure that network.target is the "marker" that signifies all network
things are brought up.

So I arranged my user services to x11.target pulling in startx.service
Then I have "Before=x11.target" in startx.service

Then in chrome.service, I have "After=x11.target"

This seems to fix my problem. It's strange since the original problem wasn't
that things were killed out-of-order.. journalctl --user -b -1 shows that all
user services are killed in the right order, just that chrome wasn't being
killed in the way I specified.

Is this expected behavior? Why didn't just doing After=startx.service do the
trick?



BTW, I reread my previous comment. The [Unit] I had posted wasn't a copy/paste,
so I left out some details.. I had a Requires= directive to trigger
deactivation. This is a copy/paste I found from a snapshot of my filesystem.

[Unit]
Description=Launch Chrome Browser
Requires=startx.service x11.target
After=startx.service

[Service]
KillMode=process
ExecStart=/usr/bin/google-chrome-unstable

TL;DR
I changed startx.service to have "Before=x11.target" and I changed
chrome.service to have "After=x11.target" instead of "After=startx.service" and
now it works as expected

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20140420/bc847f61/attachment.html>


More information about the systemd-bugs mailing list