[stupid discussion. deleted]
... with nohup. Which now doesn't work.
(Added:) The first runtime, in systemd parlance (I think), would be the session scope, the second runtime would be the user service and the third... well, something different, as you'd pass on things (group memberships, environment variables, namespaces) from your shell/session into a long-lasting service. One probably would want to extend the "once the last of my session has ended" state to the runtime of the "run forever" command.
Most non-technical users, I guess, would really prefer one of the first two lifetimes to be the default. As being able to start from a clean state after logging in- and out is rather convenient.
As nohup, in an interactive shell, is used for the third "keep running forever" option, I think it would be reasonable for distributions to alias it to the relevant "systemd-run..." command for all default shells. Then user-expectations would be perfectly met (and scripts will still run the binary /usr/bin/nohup).
> and no, unix signals are not a sane API
It might not be modern, but it's stable, widely used, and incredibly well documented. Hell, systemd is implementing this behavior using signals.
> Breaking with historical behavior is called progress.
It's not historical behavior when applications are today being developed that rely on said behavior.
Progress is building upon the best practices of the past, not breaking things because a bunch of very low quality, uneducated "developers" who all came from an alien culture simply could not think of a better, idiomatic solution.
This is the level of discourse I've come to expect from any discussion related to systemd
I think the problem people have is that systemd developers seem to actually believe this axiom.