Just lock the session instead of logging out. That would be the typical thing to do with a workstation since it runs a DE of some sort.
Jeeeeeeesus fucking Christ. Hey, instead of SSHing into a server what I'll do in future is to iLO into the console or something and run my scripts directly on the fucking terminal, eh?
If you wanted to see a systemd ignorance in all of it's idiotic nakedness, read that.
There is no change in how systemd handles either processes or logins with this change except that it purges processes that aren't explicitly allowed to continue to run.
That's an......interesting and political way of phrasing this. Unfortunately this is still a major change to default and expected behaviour even if you'd written it in Chinese;-).
This is conceptually very similar to how things always have worked
No, it isn't.
....It is simply the way to explicitly tell the system a process is allowed to survive that have changed.
Squirm, wriggle, bullshit, bullshit. This means absolutely nothing. We had a way of telling a process to persist - it was called nohup and it worked very well. There is not one single good reason why this has been changed.
So please name me just one example of breakage or non-contrived stuff that are no longer possible to do with the new systemd settings?
Expected system behaviour. Even when you close a RDP session on Windows it is still there when you get back. It doesn't transparently disappear. There is not one single good reason why this should have been changed. We'll also find out what system administration scripts this inevitably breaks for people in the coming weeks and months.
There are several benefits from the new way of doing things too, like being able to use some of systemd's extensive resource management options.
You're making this up as you go along, aren't you?
So perhaps screen, tmux, and nohup need to be modified to, on systems with systemd, do whatever the appropriate magic is necessary, just as is done on OS X.
Bloody hell. That would mean making sensible decisions and actually having a clue.
You obviously have no understanding of POSIX, no understanding of what Linux/Unix systems have had for decades, are actually describing a different solution as opposed to an alternative one and have shortened answers to "Because it is better" once you've been shown to be shooting your mouth off?
What "ALREADY FUCKING WORKS"? Applications already receive notifications to save their state when the user is being logged out or "Windows style" simply loses anything that was active without notification?
Jesus titty fucking Christ. We background the process on logout and use the resources the user has already been fucking assigned anyway. Simple. No complex saving of state which wouldn't work anyway if you're using network connections. No new APIs. No new complexity. Done. Sorted.
Because it add a huge amount of complexity, requires application support and we already have simple and well established practices where these lessons have been learned. Decades ago.
I think it is pretty obvious the systemd developers are neither lazy nor ignorant.
There is ample evidence to the contrary I'm afraid. They continuously break well established behaviour that has worked for a long time not just on Linux but Unix systems and fuck up expected kernel behaviour with userspace.
The accusation here though was that the fix here is to clean up Gnome. To think this is a solution is utterly laughable.
They may disagree with you but those sorts of accusations don't deserve a response.
They don't get a response because they are true;-).
To clarify, forcing applications to support state saving is *not* a solution because it doesn't preserve everything - TCP connections for one, as has already been pointed out to you somewhere above. We already have a solution - nohup, screen, tmux etc.
Gentoo really isn't much better. It's not as bad as Slackware, but Gentoo is still a niche distro, and its whole compilation strategy is wasteful for anyone but hobbyists.
I ran Gentoo for a long time and if you want to upgrade your distro sensibly, at this point recompilation is the only sensible option;-).
I like being finally able to hedge off a part of my processes and manage their resources in ways that login sessions and process leaders don't provide.
Which.........you haven't managed to back up, and totally misunderstood what POSIX already supplies.
Just lock the session instead of logging out. That would be the typical thing to do with a workstation since it runs a DE of some sort.
Jeeeeeeesus fucking Christ. Hey, instead of SSHing into a server what I'll do in future is to iLO into the console or something and run my scripts directly on the fucking terminal, eh?
If you wanted to see a systemd ignorance in all of it's idiotic nakedness, read that.
No I don't. I just accept technically superior solutions as the way forward, even if they means another way of working.
Simply saying that won't make it true I'm afraid. As Linus said, we don't break userspace or expected behaviour.
i thought it was very obvious, security of your system and the security of knowing what is still running legitimately after you logout.
Except that wasn't the reason. That was a reason made up on this thread. The real reason was so Gnome didn't have to be fixed on logout.
Guys I think this Peter H.S. is deliberately trolling and is writing this ridiculous stuff just to get people angry.
There's a few usual suspects that crawl on to these threads when systemd crops up.
Just edit your scripts.
This is why Linus had to tell the systemd people to go fuck themselves when they screwed up expected and working kernel and userspace interaction.
There is no change in how systemd handles either processes or logins with this change except that it purges processes that aren't explicitly allowed to continue to run.
That's an......interesting and political way of phrasing this. Unfortunately this is still a major change to default and expected behaviour even if you'd written it in Chinese ;-).
This is conceptually very similar to how things always have worked
No, it isn't.
....It is simply the way to explicitly tell the system a process is allowed to survive that have changed.
Squirm, wriggle, bullshit, bullshit. This means absolutely nothing. We had a way of telling a process to persist - it was called nohup and it worked very well. There is not one single good reason why this has been changed.
So please name me just one example of breakage or non-contrived stuff that are no longer possible to do with the new systemd settings?
Expected system behaviour. Even when you close a RDP session on Windows it is still there when you get back. It doesn't transparently disappear. There is not one single good reason why this should have been changed. We'll also find out what system administration scripts this inevitably breaks for people in the coming weeks and months.
There are several benefits from the new way of doing things too, like being able to use some of systemd's extensive resource management options.
You're making this up as you go along, aren't you?
So perhaps screen, tmux, and nohup need to be modified to, on systems with systemd, do whatever the appropriate magic is necessary, just as is done on OS X.
Bloody hell. That would mean making sensible decisions and actually having a clue.
The sensible arguments just keep getting better :-).
You obviously have no understanding of POSIX, no understanding of what Linux/Unix systems have had for decades, are actually describing a different solution as opposed to an alternative one and have shortened answers to "Because it is better" once you've been shown to be shooting your mouth off?
Sounds like a typical systemd argument to me.
I don't see people running long standing tasks after they log out of a PC........
Bloody hell.
Everyone would have been happier if one of the other solutions had panned out. The Linux community isn't used to someone just winning.
Not sure on what basis fucking up time and again is called 'winning'.
Why would I need to configure behaviour I've always had?
What "ALREADY FUCKING WORKS"? Applications already receive notifications to save their state when the user is being logged out or "Windows style" simply loses anything that was active without notification?
Jesus titty fucking Christ. We background the process on logout and use the resources the user has already been fucking assigned anyway. Simple. No complex saving of state which wouldn't work anyway if you're using network connections. No new APIs. No new complexity. Done. Sorted.
Because it add a huge amount of complexity, requires application support and we already have simple and well established practices where these lessons have been learned. Decades ago.
I think it is pretty obvious the systemd developers are neither lazy nor ignorant.
There is ample evidence to the contrary I'm afraid. They continuously break well established behaviour that has worked for a long time not just on Linux but Unix systems and fuck up expected kernel behaviour with userspace.
The accusation here though was that the fix here is to clean up Gnome. To think this is a solution is utterly laughable.
They may disagree with you but those sorts of accusations don't deserve a response.
They don't get a response because they are true ;-).
Well I'll tell you about one. The longest running popular operating system on the planet: https://en.wikipedia.org/wiki/...
ROTFL. Idiot frantically Googles around for something that seems to justify his idiotic claims.
To clarify, forcing applications to support state saving is *not* a solution because it doesn't preserve everything - TCP connections for one, as has already been pointed out to you somewhere above. We already have a solution - nohup, screen, tmux etc.
;-).
Nohup still works on OS X
You still don't understand what state is. Oh, and nohup works on OS X ;-).
Saving and restoring of state is something the process manager handles.
You *really* don't understand what state is.
.....and OS X also implement nohup properly ;-).
Not a convincing argument I'm afraid.
Gentoo really isn't much better. It's not as bad as Slackware, but Gentoo is still a niche distro, and its whole compilation strategy is wasteful for anyone but hobbyists.
I ran Gentoo for a long time and if you want to upgrade your distro sensibly, at this point recompilation is the only sensible option ;-).
The manual is rather incomplete and behaviour changes every other commit.
Eh. Wrong checkbox. That post was mine, if it wasn't obvious.
So you were wrong, can't admit it and have nothing to say? Errrr, OK.
Because the alternative mechanism is better, IMO.
Alas, simply writing this over and over this won't make it true.
I like being finally able to hedge off a part of my processes and manage their resources in ways that login sessions and process leaders don't provide.
Which.........you haven't managed to back up, and totally misunderstood what POSIX already supplies.