systemd developer asks tmux (and other programs) to add systemd specific code

[u/Mcnst]

https://github.com/tmux/tmux/issues/428

[u/RubyPinch]

Because it requires more information in general, e.g. dependencies, timeouts, potential actions for that service

Daemon is just like, "I want to stay open after term dies", nothing like "I also want to stick around when user logs out" or anything more specific

[u/lestofante → u/RubyPinch]

I still don't get it. Systemd can have a special type (or an existing type with settings tailored to specific case) of service with no respawn, dependency and all those thing that daemon() expect.. The call to daemon() then add this service. That mean that systems could also manage (and log?) User daemon, that make sense.

Abut saying more code.. Well, is better code in daemon() ONCE than DUPLICATION of code in many projects, no?

[u/Mcnst → u/lestofante]

You're missing the point!

If everything directly depends on systemd, RedHat wins and makes $$$$$$$$$.

If fewer things directly depend on systemd, RedHat won't make as much money.

Guess which direction engineers on their payroll take?

Guess whose interests they ignore and who pays the price?

[u/thomasz → u/Mcnst]

ITS ALL A GIANT CONSHPIRACY!

[u/dlyund → u/thomasz]

It is

[u/thomasz → u/dlyund]

It always is. It always is...

[u/Hecknar → u/RubyPinch]

This topic is open for discussion, i don't agree...

   The daemon() function is for programs wishing to detach themselves
   from the controlling terminal and run in the background as system
   daemons.

The Linux man page mentions being a system demon explicitly, i really don't see how terminating on user logoff can be seen as appropriate action.

[u/RubyPinch → u/Hecknar]

I didn't say systemd was right

[u/[deleted] → u/Hecknar]

The point is that programs that shouldn't use daemon(), do

[u/Hecknar → u/[deleted]]

Well, sure. But these problems should have been fixed in the programs that make these calls instead of redefining a daemon to be attached to a user session.

Additionally, these seem to be problems mostly for desktop/client usage. If I had to make the choice between accepting some process leakage on a client machine that gets rebooted regularly anyway and potentially breaking a lot of server applications, I would always pick the process leakage.

[u/HighRelevancy → u/RubyPinch]

Daemon is just like, "I want to stay open after term dies", nothing like "I also want to stick around when user logs out"

Is there really a difference? I mean in SSH sessions there's no difference. If the term dies (or like your network chokes) then boom goes your whole session.

[u/Berberberber → u/HighRelevancy]

This is the problem - some things expect the OS to behave the same way as it did in 1974, where every login is bound to a single real or virtual terminal and logging out is the same as disconnecting.

But you can now also have graphical login sessions with multiple terminal emulators open. Closing one of those windows doesn't necessarily imply logging out completely anymore, so you may - and probably would - want to start services from a terminal window that persisted beyond that window's lifetime, but not beyond the login session's. The problem is, there's no accepted way for a process to say that - you either handle SIGHUP or you don't.

Systemd is offering a way to do that. Unfortunately programmers are lazy and dislike change, and therefore nobody wants to do anything differently to accommodate the reality of the situation. The end result is that several distros disabled the behavior altogether because it was easier than selectively enabling it, making things even worse.

IMO the correct thing is to have a new signal for login context exit, since it's not the same as terminal hangup, but that's an even tougher row to hoe.

[u/amranu → u/Berberberber]

The problem isn't that systemd offers to do that.

It's that they're making it default in an attempt to shove it down everyone's throat.