Distributors ponder a systemd change
Distributors ponder a systemd change
Posted Jun 8, 2016 21:55 UTC (Wed) by JoeF (guest, #4486)In reply to: Distributors ponder a systemd change by darwish
Parent article: Distributors ponder a systemd change
And the system damn well has to follow my wishes.
A user-mode process then going and quietly killing the process against my explicit wish is a really bad thing!
They need to honor things like nohup.
Posted Jun 8, 2016 23:37 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (15 responses)
What makes you think they aren't? If you start a process with nohup then it won't be sent a SIGHUP when the shell's controlling terminal is closed, just like it says in the manual. Nothing about that has changed. It was always a rather imprecise way to manage process lifetimes, though.
Killing a user's processes on logout is hardly a new idea. This was the policy on the shared Linux servers at my university over a decade ago, for example. The ability to do this reliably with logind rather than ad-hoc scripts would be a welcome change.
Should this be the default? I'd say that's for distributions to decide. But it's a nice feature to have available, and IMHO any programs (like screen and tmux) which are meant to provide long-running services independent of the session they were started from should register themselves as separate user sessions, regardless of whether killing processes on logout becomes the default.
Posted Jun 9, 2016 18:12 UTC (Thu)
by JoeF (guest, #4486)
[Link] (14 responses)
Posted Jun 10, 2016 15:55 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link] (13 responses)
Systemd sends both SIGHUP and SIGTERM, followed some time later by SIGKILL. Your objection is mainly to the SIGKILL, but this is the same process that is used to terminate programs on system shutdown, and the correct way to end a user's session after the user logs out.
This setting is primarily about how to detect when the user's session has ended. That matters because various per-user (not per-session) background processes, most notably dbus-daemon running in user-session mode, are meant to terminate when the user's last session ends. But is the end of the session when *all* the processes started in that session exit, or when the *main* process exits? In the former case (the previous default) you end up with sessions that never terminate because they contain processes which are waiting for those per-user background processes to exit. In the latter case a handful of programs need to be more specific about the fact that they are really per-user services and not part of a particular login session—which is the right thing to do in any case.
Note that assembling a screen.service file that runs "screen -dm" as a background service outside of the session is really rather trivial, and requires no modification to the screen binary. It can be started automatically, or manually with "systemctl --user start screen@session.service".
bash$ cat ~/.config/systemd/user/screen@.service
[Service]
[Install]
bash$ systemctl --user enable --now screen@.service
The screen@.service file can also be installed system-wide as part of a system package rather than in one user's ~/.config directory. Note that you still need to run "loginctl enable-linger" in order to have the screen service (or rather, the parent user@.service) survive without any active login sessions, and you need to attach to the existing screen session rather than letting screen start a new one.
Posted Jun 12, 2016 5:59 UTC (Sun)
by elvis_ (guest, #63935)
[Link] (12 responses)
Not everyone has the time to relearn things they shouldn't have to.
Posted Jun 12, 2016 10:02 UTC (Sun)
by nybble41 (subscriber, #55106)
[Link] (11 responses)
From the point of view of either upstream or a distribution, it _is_ trivial. The template unit file can be provided as part of the screen package, and with a minor tweak to screen to do "systemctl --user start screen@$id.service" instead of running new servers directly, end-users wouldn't even need to be aware of the difference.
Even without support from the distribution or upstream there's not much to learn: run a few one-time commands to set things up—you don't need to understand unit file syntax, just copy the provided template into the configuration directory—and remember the one systemctl command needed to start a new session. Or take the quick route and (after running "loginctl enable-linger" once) alias screen='systemd-run --user --scope /usr/bin/screen'. If you can't handle that much you should probably avoid mainstream operating systems in general, as they all change at least this much on a regular basis. You might be more comfortable with one of the BSD variants, though even they aren't _completely_ static.
Posted Jun 12, 2016 23:27 UTC (Sun)
by elvis_ (guest, #63935)
[Link] (10 responses)
Posted Jun 13, 2016 6:18 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (9 responses)
No, he suggested that you should use a distribution that provides the required hand-holding if you can't be bothered to learn some pretty cool new stuff like systemd (which would incidentally come in useful in a few other places, too). Not quite the same thing.
Seriously, if you're that worked up about this, we're talking about one switch that you need to flip to make the issue at hand go away, and that's only if your distribution doesn't do it for you already. We can quibble endlessly about whether changing that default was a great idea, and there are reasonable arguments on both sides – but as far as I'm concerned, “That's not how we used to do it in 1980” is one of the less reasonable arguments.
Posted Jun 13, 2016 7:14 UTC (Mon)
by jrigg (guest, #30848)
[Link] (8 responses)
There's a big difference between "can't be bothered" and "don't have time".
Posted Jun 13, 2016 7:36 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (7 responses)
That's a lame excuse if ever I heard one.
Learning the basics of systemd takes one or two hours, tops. It's not exactly rocket science. That would cover the various types of unit files, what they contain and where they're located, how service activation works, the systemctl command and its more important subcommands, and an overview of ancillary software such as journalctl or systemd-logind. It should certainly give one enough knowledge to be dangerous and to build upon incrementally as required. There's what I would consider a reasonable primer on systemd in this manual from the tuxcademy project (although I'm biased because I wrote it myself), and Lennart Poettering's blog and the documentation on freedesktop.org are also worth a peek.
Given the importance of systemd in current and future Linux systems, one would be more than justified in considering these two hours a reasonable investment (for some people it would also be worth it just to learn enough about systemd to not appear ignorant in discussions on LWN.net). Think of it as alternative entertainment on an evening when there's nothing interesting on TV.
Posted Jun 13, 2016 10:50 UTC (Mon)
by johannbg (guest, #65743)
[Link] (2 responses)
People that approach and view systemd as a new technology with new concepts adapt to it quicker than those with any background in any legacy init system in which they more often than not approach systemd as an legacy init system and apply legacy init system concepts that are not applicable to systemd ( and expect same and similar outcome or behavior ) like for example the concept of "run levels" which does not exist in systemd but the concept of boot targets does etc.
Posted Jun 13, 2016 12:22 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (1 responses)
In my experience as a Linux instructor, one or two hours of systemd instruction is adequate to provide the basics for people who would otherwise be using System-V init as system administrators. Building on that, it is certainly more feasible to spend another couple of hours teaching somebody how to write a systemd service unit file for a new service and to integrate that into an existing setup, than it is to spend a couple of days teaching them enough shell scripting and distribution-specific minutiae to be able to write a robust System-V init script for a new service and to integrate that into an existing setup, on one single distribution. (The next distribution is going to be subtly, or not so subtly, different.)
For an upstream project, it is reasonable to invest the time to produce a good systemd-based configuration, which by now is likely to be applicable with few if any changes to a large number of platforms, because the effort for that is going to be smaller, in the long run, than the effort required to test and tweak new versions of their application (or application stack) on a huge number of subtly different legacy environments that all require some degree of individual adaptation.
Posted Jun 13, 2016 16:01 UTC (Mon)
by johannbg (guest, #65743)
[Link]
Daemon vs socket activation, path used in type units and simply the name of the component ( apache vs httpd for example ) etc still differs between distributions and that problem will never be solved unless unification in the core/baseOS can be achieve so those upstream(s) that actually care and ship initscripts of any kind are still dealing with that issue.
Posted Jun 13, 2016 12:38 UTC (Mon)
by jrigg (guest, #30848)
[Link] (2 responses)
It's easy to say that's purely a problem for the distros, but system upgrades are painful enough without having to learn several different versions of things in preparation for the next one.
Posted Jun 13, 2016 20:58 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Jun 14, 2016 13:05 UTC (Tue)
by jrigg (guest, #30848)
[Link]
According to this, https://www.freedesktop.org/wiki/Software/systemd/MyServi... the way to allow realtime scheduling for users for a specific service is to add ControlGroup=cpu:/ to its [Service] section. The ControlGroup= option was removed in systemd 205 (July 2013) but the document hasn't been changed. That's an example of what I was referring to.
To be fair it's only one specific example, but it did contribute to my decision to stick with sysvinit-core on my Debian systems for the time being.
Posted Jun 13, 2016 13:23 UTC (Mon)
by paulj (subscriber, #341)
[Link]
That's the basics of good system maintenance.
Posted Jun 15, 2016 3:54 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Most of my "nohup" processes are things like image and PDF viewers for opening attachments from mutt so that the viewers don't close when I close the tmux window. I don't think `nohup` means "should persist the session" at all; something stronger needs to be done (I have it on my TODO list to do some experimentation with a "new-session" wrapper application to start a PAM session).
Distributors ponder a systemd change
Distributors ponder a systemd change
They should send SIGHUP, or not send anything at all.
Distributors ponder a systemd change
[Unit]
Description=screen
Type=forking
Restart=always
ExecStart=/usr/bin/screen -dmS %I
ExecStop=/usr/bin/screen -S %I -X quit
WantedBy=default.target
DefaultInstance=autoscreen
bash$ systemd-cgls # Amended for brevity
Control group /:
-.slice
└─user.slice
..├─user-XXXX.slice
..│..├─user@XXXX.service
..│..│..└─screen.slice
..│..│......└─screen@autoscreen.service
..│..│..........├─27015 /usr/bin/SCREEN -dmS autoscreen
..│..│..........└─27016 /bin/bash
..│..├─session-2.scope
..│..│..├─ 2216 /bin/sh /usr/bin/startkde
bash$ screen -ls
There is a screen on:
........27015.autoscreen........(06/10/2016 10:31:12 AM)........(Detached)
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
You awareness is incorrect. Systemd is committed to backwards compatibility, so my units from 2012 still work just fine.
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change