I don't see people running long standing tasks after they log out of a PC as being a major use case and therefore it makes sense is the default doesn't allow it to happen.
You don't do any system administration on servers then.
This is the kind of convoluted crap I'd expect really, which again, has no real world basis because those sensible enough don't run something this stupid. Those that do run [very] unstable applications;-).
You restart C under daemon tools or something, anything will do, and then reconnect the database. You also want logs to output when this happens. Creating a complex system to manage this is just insanely stupid.
The principle of least astonishment is following systemd policies.
Policies which change every week, or change based on Gnome having bugs they don't want to fix;-). That's the exact opposite of least astonishment, actually.
OS X and iOS does not save state the manner required I'm afraid so I don't know what you're talking about there. It's a ridiculously complex and rather silly thing to do when you can just persist processes when needed.
who needs to be sure that users who have left the employ of the organisation don't have the ability to run commands anymore.
This is a highly complex process of removing their user logins.
Without this control available, I need to check every server for screens or nohup'd processes (we already have controls in place for at, cron etc.).
What gives you the idea that this is what it will do? Users have a wide variety of reasons for running screen, and under systemd you're still going to have to make provision for users to run screen and nohup etc........because they're useful. It is not going to run round all your servers and clean up long running processes.
This has been a real risk in the past on real servers currently running sysvinit.
What's sysv got to do with this? Ahhh, yes, I see what's going on here........;-).
With this systemd feature, it would make my life easier, because on the two bastion/hop servers, I would disable this and audit processes on these servers when removing/locking accounts.
Disable what? So they'd only be able to do 'unsafe' stuff while they are logged in?;-) Why do you think this will improve security? Are you not auditing already when you remove user accounts? I can't figure what on Earth you think will be improved here.
No, just because sysvinit can't enforce it well doesn't mean no-one needs it.
...and would also know not to use Debian Sid on a critical server, BTW.
Errrr, Sid eventually turns into 'stable'........?
screen DOES work as intended as long as you care to correctly start it in its own seat/session/namespace/container (and all those non-POSIX-y stuff that Linux handles and that systemd manages)
Which doesn't qualify as working. Quite why people think something should have to be run differently when you are logged out as when you are logged in is truly mystifying.
Only the process manager has the global knowledge of the competing demands to make intelligent choices about resource allocation. Given competing demands for a system to work well intelligent choices need to be made about what should be running when. That's systemd's job.
That is utterly meaningless and simply shift the goalposts yet again as to why this change was made. I've lost count of the number of reason changes we've had. Security, resource allocation, wind blowing from the east........
and i posit that the security of knowing what is legitimately running on my system after log out is reason enough.
It's all about security now - from someone who doesn't know shit about it. The reasons for this farcical piece of nonsense change every minute. The initial reason is because Gnome couldn't clean up after itself.
Why do you think there no solid reasons for this new default. It is something somebody told you, or are you just presenting what you imagine as facts?
Th reason for this new default is because Gnome wasn't cleaning up after itself and no one could be bothered to find out why. Killing everything after logout was the only fix they could find: https://lists.fedoraproject.or...
Same example I've given you. A depends on B depends on C depends on D depends on E. C crashes and the system is able to recover. What does the operating system do with A, B, D and E to get them aligned with the new state?
I've never encountered this scenario. You know why? Because it's hypothetical nonsense.
yawn... Pen and paper used be the way to do things so whats your point?
Yawn..... It still works.
if you don;t like tightening up security on your systems, thats up to you.
What the fuck has this got to do with security, from someone who obviously knows squat about it?
I presume most of the anti are like the manual workers of old who were worried that computers would take away their jobs and in this instance systemd is taking away manual tasks from you.
Which has no relevance to what's being discussed. Bloody hell........ I'd recommend you stick to the recommended dose for whatever your meds are.
Probably quite a bit because no-one does any research on the issue before winding their neck out and making random ignorant statements especially as its just a configure change not a functional one.
A better suggestion would be that before systemd developers start making changes to default behaviour that has been around for decades, for good reason, that they actually work out why said behaviour was that way to start off with.
Sessions != individual users and login/logouts. Any system that does that has just gone backwards.
"systemd 230 now finally flipped the switch and finally by default cleans everything up correctly when the user logs out. But we do so in a very conservative way actually:
Which was done because the imbeciles couldn't fix Gnome and clean up its shit on exit. 'Very conservative' my arse. You've got to love the slippery political statements they spew out when they fuck up.
a) there's a compile time switch to turn this off globally (--without-kill-user-processes, not used in Fedora)
Wow, recompiling. Really helpful.
b) there's a runtime switch to turn this off locally on the system (in logind.conf)
Not default, expected behaviour.
c) there's a way to opt-out invidually for each user and each task from the cleanup logic, via systemd-run/loginctl linger. This operation goes through PK, and thus can be configured in a more strict or more open policy, depending on whhat the admin prefers.
Yay. I get to run through all the commands in/usr/bin et al and explicitly tell it I'd like them to persist - even though I'm already explicitly fucking doing that with nohup or something else because that's what those commands are for.
Because they are remote headless systems and I don't need to stay connected to them in order for them to do the stuff I want them to do?
Wow. Why ever would you want to do that? \sarcasm The systemd model is that everything you do starts after a login and ends with a logout. For those of us with experience this is stupid beyond words.
And tell your system you want that. You can change default config on Unix.
We have never needed to tell our 'system' that before. Plus, there are a long laundry list of commands (errrrr, everything a user has permission to run anyway) that a user can run that can be persisted. To have to 'register' them all is idiotic. Sessions != [necessarily] individual users, for good reasons, and to try and equate the two is just out and out stupidity. A system that restricts based on logins and logouts is totally broken.
What the... ?? Is this a troll? You can't be serious. C'mon - what the hell is this shit?
Yes it is a troll, and the same usual suspects crawl out of the woodwork on here every time when systemd fucks something else up. Anyone who has done system administration for any length of time knows that sessions != individual users for very good reasons and anyone who tries to equate the two hasn't the faintest idea what he's talking about. We'll eventually regress to single user systems.
systemd allow you to have processes not tied to a session. That hasn't changed.
Slippery political bullshit, which means zilch. Long-standing, expected behaviour has been changed here because lazy morons can't work out why Gnome won't clean up after itself.
You just have to tell the system and have permissions to do it.
Sensible systems allocate resources and allow users to use them. I know of no other system out there that requires you to register every single process type you might want to run beyond a user session so that when you log back in you pick up where you left off. You know why? Because it's fucking stupid.
Wouldn't it be better to save state on logout and restore on login?
Why?
This would provide the balance between saving system resources and allowing a user to start off where they left off.
What resources do you think you're going to be saving here? There are various ways of allocating resources to a user and they then use those how they want. restricting this to log on and log off is incredibly stupid.
Of course applications would need to be aware of state saving. Is there already some sort of API for this?
Jesus Christ. We don't need an API, or to add systemd support to anything because it ALREADY FUCKING WORKS.
A multi-user system shouldn't allow unpriviledged users from consuming resources indefinitely. It's too easy to starve a system or resources.
Errr, setting appropriate user resources is the way to do this, and there are various methods to do that. Killing everything isn't, and there are any number of things you'd want to leave running so that when you log back in you log back in to the same state. This is the kind of moronic nonsense you get when developers override system administration practices that have been around a very long time for a reason.
Slashdot Mirror
I don't see people running long standing tasks after they log out of a PC as being a major use case and therefore it makes sense is the default doesn't allow it to happen.
You don't do any system administration on servers then.
This is the kind of convoluted crap I'd expect really, which again, has no real world basis because those sensible enough don't run something this stupid. Those that do run [very] unstable applications ;-).
You restart C under daemon tools or something, anything will do, and then reconnect the database. You also want logs to output when this happens. Creating a complex system to manage this is just insanely stupid.
You have heard. Process management.
Which depends on kernel features. Why do I need systemd again?
The principle of least astonishment is following systemd policies.
Policies which change every week, or change based on Gnome having bugs they don't want to fix ;-). That's the exact opposite of least astonishment, actually.
OS X and iOS does not save state the manner required I'm afraid so I don't know what you're talking about there. It's a ridiculously complex and rather silly thing to do when you can just persist processes when needed.
You don't understand what state is. Re-read your steps. There is absolutely nothing in here about how state is saved.
who needs to be sure that users who have left the employ of the organisation don't have the ability to run commands anymore.
This is a highly complex process of removing their user logins.
Without this control available, I need to check every server for screens or nohup'd processes (we already have controls in place for at, cron etc.).
What gives you the idea that this is what it will do? Users have a wide variety of reasons for running screen, and under systemd you're still going to have to make provision for users to run screen and nohup etc........because they're useful. It is not going to run round all your servers and clean up long running processes.
This has been a real risk in the past on real servers currently running sysvinit.
What's sysv got to do with this? Ahhh, yes, I see what's going on here........ ;-).
With this systemd feature, it would make my life easier, because on the two bastion/hop servers, I would disable this and audit processes on these servers when removing/locking accounts.
Disable what? So they'd only be able to do 'unsafe' stuff while they are logged in? ;-) Why do you think this will improve security? Are you not auditing already when you remove user accounts? I can't figure what on Earth you think will be improved here.
No, just because sysvinit can't enforce it well doesn't mean no-one needs it.
This has nothing to do with sysv...........
...and would also know not to use Debian Sid on a critical server, BTW.
Errrr, Sid eventually turns into 'stable'........?
screen DOES work as intended as long as you care to correctly start it in its own seat/session/namespace/container (and all those non-POSIX-y stuff that Linux handles and that systemd manages)
Which doesn't qualify as working. Quite why people think something should have to be run differently when you are logged out as when you are logged in is truly mystifying.
no user process will be killed on exit/logout if the user have told the system not to.
Why would I need to tell the system? I didn't before and sessions != users.
Only the process manager has the global knowledge of the competing demands to make intelligent choices about resource allocation. Given competing demands for a system to work well intelligent choices need to be made about what should be running when. That's systemd's job.
That is utterly meaningless and simply shift the goalposts yet again as to why this change was made. I've lost count of the number of reason changes we've had. Security, resource allocation, wind blowing from the east........
This is hypothetical tripe where you won't be able to provide one single real-world example. Repeating it won't justify anything, alas.
and i posit that the security of knowing what is legitimately running on my system after log out is reason enough.
It's all about security now - from someone who doesn't know shit about it. The reasons for this farcical piece of nonsense change every minute. The initial reason is because Gnome couldn't clean up after itself.
Why do you think there no solid reasons for this new default. It is something somebody told you, or are you just presenting what you imagine as facts?
Th reason for this new default is because Gnome wasn't cleaning up after itself and no one could be bothered to find out why. Killing everything after logout was the only fix they could find: https://lists.fedoraproject.or...
You could have written a far shorter sentence that would would have listed something useful that systemd actually did.
Same example I've given you. A depends on B depends on C depends on D depends on E. C crashes and the system is able to recover. What does the operating system do with A, B, D and E to get them aligned with the new state?
I've never encountered this scenario. You know why? Because it's hypothetical nonsense.
yawn... Pen and paper used be the way to do things so whats your point?
Yawn..... It still works.
if you don;t like tightening up security on your systems, thats up to you.
What the fuck has this got to do with security, from someone who obviously knows squat about it?
I presume most of the anti are like the manual workers of old who were worried that computers would take away their jobs and in this instance systemd is taking away manual tasks from you.
Which has no relevance to what's being discussed. Bloody hell........ I'd recommend you stick to the recommended dose for whatever your meds are.
Correct. systemd is part of a broader system that is replacing POSIX.
ROTFL. Oh, right. systemd gets a new purpose in life every week. So, what happened to the init system then?
Probably quite a bit because no-one does any research on the issue before winding their neck out and making random ignorant statements especially as its just a configure change not a functional one.
A better suggestion would be that before systemd developers start making changes to default behaviour that has been around for decades, for good reason, that they actually work out why said behaviour was that way to start off with.
Sessions != individual users and login/logouts. Any system that does that has just gone backwards.
"systemd 230 now finally flipped the switch and finally by default cleans everything up correctly when the user logs out. But we do so in a very conservative way actually:
Which was done because the imbeciles couldn't fix Gnome and clean up its shit on exit. 'Very conservative' my arse. You've got to love the slippery political statements they spew out when they fuck up.
a) there's a compile time switch to turn this off globally (--without-kill-user-processes, not used in Fedora)
Wow, recompiling. Really helpful.
b) there's a runtime switch to turn this off locally on the system (in logind.conf)
Not default, expected behaviour.
c) there's a way to opt-out invidually for each user and each task from the cleanup logic, via systemd-run/loginctl linger. This operation goes through PK, and thus can be configured in a more strict or more open policy, depending on whhat the admin prefers.
Yay. I get to run through all the commands in /usr/bin et al and explicitly tell it I'd like them to persist - even though I'm already explicitly fucking doing that with nohup or something else because that's what those commands are for.
Because they are remote headless systems and I don't need to stay connected to them in order for them to do the stuff I want them to do?
Wow. Why ever would you want to do that? \sarcasm The systemd model is that everything you do starts after a login and ends with a logout. For those of us with experience this is stupid beyond words.
And tell your system you want that. You can change default config on Unix.
We have never needed to tell our 'system' that before. Plus, there are a long laundry list of commands (errrrr, everything a user has permission to run anyway) that a user can run that can be persisted. To have to 'register' them all is idiotic. Sessions != [necessarily] individual users, for good reasons, and to try and equate the two is just out and out stupidity. A system that restricts based on logins and logouts is totally broken.
1) FTP command line registers with systemd that's its going to be doing a download over the next 12 hours from a slow server.
Jesus Christ..............
What the ... ?? Is this a troll? You can't be serious. C'mon - what the hell is this shit?
Yes it is a troll, and the same usual suspects crawl out of the woodwork on here every time when systemd fucks something else up. Anyone who has done system administration for any length of time knows that sessions != individual users for very good reasons and anyone who tries to equate the two hasn't the faintest idea what he's talking about. We'll eventually regress to single user systems.
systemd allow you to have processes not tied to a session. That hasn't changed.
Slippery political bullshit, which means zilch. Long-standing, expected behaviour has been changed here because lazy morons can't work out why Gnome won't clean up after itself.
You just have to tell the system and have permissions to do it.
Sensible systems allocate resources and allow users to use them. I know of no other system out there that requires you to register every single process type you might want to run beyond a user session so that when you log back in you pick up where you left off. You know why? Because it's fucking stupid.
Wouldn't it be better to save state on logout and restore on login?
Why?
This would provide the balance between saving system resources and allowing a user to start off where they left off.
What resources do you think you're going to be saving here? There are various ways of allocating resources to a user and they then use those how they want. restricting this to log on and log off is incredibly stupid.
Of course applications would need to be aware of state saving. Is there already some sort of API for this?
Jesus Christ. We don't need an API, or to add systemd support to anything because it ALREADY FUCKING WORKS.
A multi-user system shouldn't allow unpriviledged users from consuming resources indefinitely. It's too easy to starve a system or resources.
Errr, setting appropriate user resources is the way to do this, and there are various methods to do that. Killing everything isn't, and there are any number of things you'd want to leave running so that when you log back in you log back in to the same state. This is the kind of moronic nonsense you get when developers override system administration practices that have been around a very long time for a reason.