Hacker News Reader

Comment by dijit | Hacker News Reader

This came up about a week ago, I questioned why it was a useful feature and people were quick to bark "security, if you don't like it you should be writing service/unit files for your programs."

To me, I can't think of a single other operating system that works this way, even Windows. But I'm sure the pro-systemd supporters will "correct" my thinking.

Additional: "You can just disable it, don't worry about the defaults" will be another argument that comes up, seems to be a nice way of stopping discussion.. it's the same thing people espoused when binary logging/journalctl was enforced.

View on HN

Can you write service/unit files for irc clients like irssi, or one-shot file transfers like rsync or wget?

This is crazytown.

Edit: I guess I should take the massive amount of downvotes to mean that it is in fact not crazytown to write service and unit files for one-off downloads or backgrounded TTY clients, and anyone asking for more information on this does not deserve a reply. Ok.

You wouldn't have to write service/unit files for one off commands. The release notes mention that you can use 'systemd-run' to start these[1].

[1] - https://github.com/systemd/systemd/blob/master/NEWS#L29

Looks like that's not enough, you also need to set some sort of "lingering" option or the last logout will kill everything despite having used systemd-run?

Sounds like a lot of pitfalls with these new defaults. Wonder how many background tasks will be ruined before somebody patches screen to automatically issue all these new systemd commands.

I don't think the 'lingering' option is necessary. That controls the default behavior for processes. Systemd-run basically makes a one off user level service.

Looks like I was wrong. You do have to enable lingering[1].

[1] - https://wiki.archlinux.org/index.php/Systemd/User#Automatic_...

Wow, talk about insane...

I actually do wish I could write a unit for things like irssi... if it dies, I want systemd to restart it, and if my entire machine reboots, I want systemd to restart it on boot as my UID.

You can do this with user level systemd instances: https://wiki.archlinux.org/index.php/Systemd/User

To me, I can't think of a single other operating system that works this way, even Windows. But I'm sure the pro-systemd supporters will "correct" my thinking.

Windows has stopped all the programs I had ran when I log out for as long as I remember.

But Windows also allows a session to disconnect without logging out. (This is the default when a remote session disconnects from the client side or due to network errors, and is prominently displayed in the UI otherwise.)

For an ssh session on Linux, the traditional equivalent would be to run tmux/screen in the background, but systemd will happily kill them.

You can similarly disconnect a VNC to a GNU/Linux desktop without logging it out.

Speaking of which, if you run an Xvnc server in the background out of your shell and log out, this systemd problem will now kill it.

For RDP - Windows doesn't spawn a new session every time you remote into a machine if there's already an existing one, and closing the RDP window without logging out leaves the session running.

But then again, the closest equivalent I can think of to an SSH session is Enter-PSSession, which does close all processes started under it when closing the session with Exit-PSSession.

Closing the RDP session is equivalent to locking your session (lock screen) and not equivalent to log out. However, in Linux exiting an SSH is like a log out, is it not?

Yes, that is what I meant.

Yes, you can disable it if you have root on that system where you're trying to use tmux or whatever.

But what if I don't have root? Like on production let's say.

Then start your process with `systemd-run`. nohup is so three decades ago.. :(

This is more a case of "nohup was broken anyway, so we are well within our rights to do whatever we want. We'll write our own new API for it in a version or two."

So where's the explanation of how nohup is broken enough to be worth breaking the rest of the way and replacing with a more complex non-portable alternative?

I was speaking in general, you probably won't be getting that explanation until enough people post a bug about it on Red Hat's bugzilla. Then we'll get the usual dance of systemd maintainers saying it's working as intended, users saying it used to work differently, systemd maintainers saying that the old behaviour was wrong and users were stupid to rely on it, etc.

So, like this one: https://bugzilla.redhat.com/show_bug.cgi?id=753882#c29

Reply on news.ycombinator.com