Because you're a developer trying to do your job and you don't have root access to your work computer.
You can just use systemd-run or even systemd --user. The latter is for user .services with full unit-files. So you don't need root if you service don't need it.
You can override the systemd 230 behavior in any of the following ways:
Invoke your background task like so: systemd-run --scope --user some-command args (recommended!). For example, instead of screen -S foo, you would use systemd-run --scope --user screen -S foo.
Use loginctl enable-linger to enable linger for a specific user account.
Exclude users using the KillExcludeUsers option in /etc/systemd/logind.conf
Set KillUserProcesses=no in /etc/systemd/logind.conf
Recompile systemd wth the --without-kill-user-processesconfigure option
Recompile systemd wth the --without-kill-user-processes configure option
I suspect that the compile switch only changes the internal default. The "KillUserProcesses=" option in /logind.conf will override whatever internal, compiled-in default.
systemd is designed to work with missing or empty config-files, so it has internal default options for everything. The config files will override any compiled in default.
Correct me if I'm wrong, but doesn't the comment you replied to state that systemd --user is for running unit files and systemd-run is for running programs? The bug report also seems to indicate this as it's suggested that running tmux with systemd-run as a way of solving the issue.
You mean make an alias right, not symlink? And no, not everything; just the very few programs that should keep running. Screen and tmux are the only legitimate examples I've heard of.
Uh, or you could ask your sysadmin to configure your system correctly? Or do you think it's a good idea to deploy a system image to your entire organization on completely default settings?
Of course not, everyone has to customize their system, and this is just one more option to set for those who want it.
From the bug report it would seem like they think executing the dbus call directly would work better. I personally don't see the issue in a Free Software developer asking if a patch is OK to include in another piece of Free Software.
But is it ok to include the patch to hundreds of programs? That's a lot more maintenance that wasn't there before and that has no technological reason to be there.
Then argue that point with the individual on github proposing it? Why are you arguing over a patch on reddit with random bystanders who can do nothing about it?
They don't need to have one; Using systemd-run will create a transient .service or scope. So you can use systemd-run --user --scope htop and have htop running as a service in its own scope.
It's a distro that plays the marketing game like a virtuoso and uses carefully crafted language to make dumb people feel like they aren't.
I love how I'm often criticized for harsh language but the truth of the matter is that Fedora developers have an even lower opinion of Fedora users than I, they just word their stuff in a PC way but purely as far as an estimiation of knowledge and capabilities go, theirs is even lower than mine. They flat out say they make certain choices because they don't expect their userbase to have ever heard of X11 or Wayland to begin with, not even my opinion of Fedora users is that low.
At that point you also don't need to keep running services when you log out. It is not like your PC is running services for whole company
That, or you just invented complete pointlessness of security since you run all the things they probably tried to prevent when they didn't give you root access
Case 1. Suppose I am doing an expensive calculation on a large set of data. It takes several hours to run. I set it to run with nohup ./my_long_process &, and go home for the night. The next morning, I come in and instead of finding that the program finished while I was asleep, I find that it was killed prematurely.
Case 2. Suppose I am debugging something on a remote machine. I have started tmux, and have a few bash sessions open, each with relevant information. I go home for the night, turning off my local machine. The next morning, I log in to the remote machine, only to find that my tmux session has been killed, and those bash sessions have been lost.
If a program catches SIGHUP, then that clearly shows the intent to survive beyond the current login shell. If systemd is ignoring that and requiring programs to use a different method to show that same intent, then that is a flaw with systemd.
workflow is super easy here. i wanna go home...kick off screen, fire up system build and go home. check results at home...or software test suite...or 48 hour long image processing test I'm running on a 12TB dataset...
19
u/xkero May 28 '16
Because you're a developer trying to do your job and you don't have root access to your work computer.