systemd 253 RC1 Released With New "ukify" Tool

[Xake]

While it can be a very good tool in tightly controlled environments such as servers, the current approach is a clusterfuck on the desktop.
Nobody likes it when their apps, or even their entire desktops, suddenly disappear with no warnings, no clues, no way to appeal, and no way to recover anything.

How is this any different from how the linux kernel handle oom if no systemd-oomd? That is kill random process, and if your are lucky it is not Xorg it deemd to be the process to kill.
Or do you prefer the windows way? That is: lock up you computer until you hard reset.

Now, for this or -any other- proactive oom-handler to be viable on the desktop, integration and more functionality are imperative.
I mean, currently It's criminal! There's not even a notification after the fact.

For general acceptance we need desktop-centric functionality, a GIU for easy configuration by laypeople, and some sweeteners:

You make it sound like it kills long before anyone notice any problem with regards to system load. That is not my experience. At all.
When was the last time you actually oom-ed?

Me myself has done it a couple of times lately due to a somewhat unstable dev environment. And for me it starts to show I am running out of memory long before systemd-oomd does anything.
Also on my home-server running a daemon with a known memory leak, if I have forgotten to restart that daemon for about two month ssh will for a short while stop working until systemd-oomd has done its things.

The only thing I can think of that leads to you getting OOMs without any system impact beforehand is if you are one of those who due to loads of misconceptions has turned of swap on their systems.

[ClosedSource]

Whatever happened to "innocent until proven guilty"...

Having your own agenda behind your project doesn't make you guilty.

[Alliancemd]

Imagine bringing so much progress to the Linux ecosystem, improving stability and security, just to get hatred from a bunch of idiots not having any understanding of what it does...

[NotMine999]

Imagine bringing so much progress to the Linux ecosystem, improving stability and security, just to get hatred from a bunch of idiots not having any understanding of what it does...

I don't think the "hatred" (as you call it) is due to WHAT the systemd developers did...rather it is THE WAY they did it...the "take over everything" approach...followed by almost every distro in creation failing all over themselves (and some in a mad rush while others, like Debian were slower to succumb) to convert to systemd.

But systemd may have problems. As post #20 points out (thank you Andy), sometimes the systemd developer crowd can get into (or really close to) very deep water and with no way out. In the USA there is an old saying, "You break it - You bought it". Once systemd developers "touch" something then it's on them to fix it and there's nobody else to blame.

My own view of systemd is, and has been for a while, the more distros converge on common concepts like systemd, the harder those must work to differentiate themselves in order to retain their raison d'être. It's like the days of the old Model T Ford...you can have any color you wanted so long as it was black. Srsly all original Model T Fords were painted black.

Just spinning up a different theme & collection of packages is not enough to justify the existence of a Linux OS anymore. Anyone remember the days of OS "spins" in Fedora? IMHO Ubuntu was a successful "user friendly spin" of Debian with some interesting features (IMHO 'Upstart' actually was pretty good and worked in a predictable manner), but then Ubuntu went down a rabbit (worm?) hole or whatever that hole is called. A new & better package manager tied to a vast universe of tested & maintained packages and timely kernel releases goes much much further to justify an existence than just having a pretty DE & GUI tools.

IMHO all systemd does is make Linux more like Windows where users are not expected to learn about the OS that they use in order to use that OS to it's fullest potential - Windows intentionally limits a user's (and even a sysadmin's) ability to use it to it's fullest potential while a non-systemd Linux system does not limit the user (if the user has root access). After all, Linux is about respecting the user's choice, right?

[NobodyXu]

IMHO all systemd does is make Linux more like Windows where users are not expected to learn about the OS that they use in order to use that OS to it's fullest potential - Windows intentionally limits a user's (and even a sysadmin's) ability to use it to it's fullest potential while a non-systemd Linux system does not limit the user (if the user has root access). After all, Linux is about respecting the user's choice, right?

What ability or potential does systemd prevent you from archiving?
And what's wrong with making OS features more accessible, e.g. sandboxing long-running process using namespace, seccomp, annoymous one-time use user/group, etc?

You still need basic OS knowledge to use systemd anyway.
Like, if you don't even understand what a daemon is, you are sure in big trouble.

systemd does replace the shell script used by sysvinit with declaration style file, which makes it far easier to use without these less messy, fragile shell script.
IMO shell scripts are unsuitable for anything longer than 20 lines, unless the shell scripts are generated from another PL.

About user's choice...

Well, linux started as a exercise and then is adopted by companies to avoid unix loyalty fees while unifying the OS used on servers.
Then it was adopted by Google to use on phone, called Android.

It is open source, so anyone can come, modify the code and contribute, but that's about the limit of it.
I don't think there's anywhere saying linux's goal is for respecting users' choices, I'd like to think of it as a side effect of being open source.

In fact, the GNU toolchain also doesn't say about users' choices, but rather about GPL, about being open source and force users who modify the source code to contribute back instead of starting their own proprietary implementation, which again, unifies and avoid having proprietary toolchain, though it also has its downsides which is why LLVM comes.

[oiaohm]

IMHO all systemd does is make Linux more like Windows where users are not expected to learn about the OS that they use in order to use that OS to it's fullest potential - Windows intentionally limits a user's (and even a sysadmin's) ability to use it to it's fullest potential while a non-systemd Linux system does not limit the user (if the user has root access). After all, Linux is about respecting the user's choice, right?

https://0pointer.de/blog/projects/systemd.html This more like windows when talking about systemd need to stop. Systemd is make Linux more like MacOS and Solaris in service management. Driving force is launchd with a little bit of SMF from Solaris for good measure. Yes Apple gets mentioned 5 times in the founding concept idea of systemd and Solaris gets mentioned 3 times windows gets mentioned exactly zero times. Upstart gets mentioned the most times.

Yes systemd first developer looked at launchd and upstart before making systemd as well.

Old Non-systemd system does end up limiting users as well.

https://github.com/systemd/systemd/issues/13101

Systemd is also not past having problems with the Linux kernel process management system. This is a problem lot of non-systemd Linux systems are in fact using service management systems that are not in fact Linux kernel compatible and are basically some what working by good luck not good design.

Also non-systemd system even if you have root can still be mega limited. LSM(Linux Security Modules) are higher authority than root user.

Yes it one thing to respect user choice is another thing to be serving up known broken implementation.

[NobodyXu]

NotMine999 I just remember a bug reminded by oiaohm that likely hits sysvinit because it uses mainly shell scripts.

The bug is the PID recycle problem.
On Unix, the PID wraps around once it hits the pre-set limit (I think it is sth. like 65535, which is the max of u16, but it can be raised) or the maximum value representable by a u32.

Shell script can only use pid to recognize a process, so if a long-running process with pid = 40 dies, which is quickly reaped by bash as it is designed to do so, then a new process starts and the kernel needs to allocate a pid for it.
Says that the pid reaches the max value and wrap around, but all pid < 40 is used by other processes already, so the new process has the same pid as the old one.

Now you have the problem of pid cannot uniquely identify a process, a huge problem for an init system.

The only way around this is to use clone with CLONE_PIDFD flag when creating a new process to obtain a pidfd which is basically a fd uniquely identify a process, or use pidfd_open when you are sure waitpid will not be called until this operation is done.

None of this is available when writing bash scripts, of course, and bash script's aren't good at managing fds even if you expose these functionalities via an extension, plus shell scripts are so easy to get wrong, e.g. the quoting, mixing of env, global and local variables, no strong typing, everything treated as str, etc.
The only sane way to implement an init system is to use a strong-type language, preferably memory safe and also a compiled language for performance.

[oiaohm]

On Unix, the PID wraps around once it hits the pre-set limit (I think it is sth. like 65535, which is the max of u16, but it can be raised) or the maximum value representable by a u32.

That is not quite right. When you go back to system V Unix you find out it does not PID wrap instead it simply kernel panics when you get to max value for PID yes made fork bomb back then way worse. Yes sysvinit on Linux is based of the System V Unix init design that is absolutely not Linux kernel compatible because it was not designed for PID recycling.

Safe kill process/application using pidfd would be possible, Yes pure shell script it not possible to do service management correctly without extending shell script language but its not as much of extend as one would think.

https://copyconstruct.medium.com/bas...s-e799ec5a3c16
Shell script does in fact have file descriptors.
exec 6< bar.txt
exec 6<&-
First line is open file handle 6 second line is close file handle 6.

Yes there would need to be extend to allow PID to be assigned to one of the bash file handles and to allow signal to be sent to one of these file handles. I do agree going to be messy as hell and it questionable if it worth it.

Cgroup usage by systemd is also about putting more on a process to be sure you are killing the right one. Yes two problem with the historic PIDFILE solution
1) Is not enough information to be sure you have the right thing on a system that recycled PID.
2) PID value is race conditioned with PID recycling.

Yes its not just sysvinit that goes and uses the busted PIDFILE solution.

[NobodyXu]

That is not quite right. When you go back to system V Unix you find out it does not PID wrap instead it simply kernel panics when you get to max value for PID yes made fork bomb back then way worse. Yes sysvinit on Linux is based of the System V Unix init design that is absolutely not Linux kernel compatible because it was not designed for PID recycling.

I'm referring to the init system called sysvinit, not other unix system.

Safe kill process/application using pidfd would be possible, Yes pure shell script it not possible to do service management correctly without extending shell script language but its not as much of extend as one would think.

https://copyconstruct.medium.com/bas...s-e799ec5a3c16
Shell script does in fact have file descriptors.
exec 6< bar.txt
exec 6<&-
First line is open file handle 6 second line is close file handle 6.

I know bash can opened fd like that, but doesn't change that fact that this is extremely hacky.
You would have to implement an extension that provides pidfd_open (or clone with CLONE_PIDFD), pidfd_send_signal, waitid and close for that to work.
I once implemented an extension in bash https://github.com/NobodyXu/bash-loadables and honestly do not like implementing this since there is not much doc/example and I have to read the bash source code, which sucks because some of them isn't even C89 but K&R.

Not to mention bash doesn't have RAII (though C also doesn't) and lack of strong typing.
You can't even specify the argument list and their types when defining a function.

Yes two problem with the historic PIDFILE solution
1) Is not enough information to be sure you have the right thing on a system that recycled PID.
2) PID value is race conditioned with PID recycling.

Yes its not just sysvinit that goes and uses the busted PIDFILE solution.

Does PIDFILE refer to open /proc/$pid?
I have no experience with that, but it doesn't stop pid recycling.

In fact, not even pidfd_open or clone with CLONE_PIDFD can stop it.
Once it is waitpid/waitid on, it is recycled.

[oiaohm]

Does PIDFILE refer to open /proc/$pid?
I have no experience with that, but it doesn't stop pid recycling.

https://man7.org/tlpi/code/online/dist/filelock/create_pid_file.c.html

The historic Unix style PIDFILE is past dumb. You take a process current PID value write that into a file and use that latter to kill a process or something and hope nothing bad has happened in the middle. Yes the only information about the process in the pidfile be the PID number.

https://wiki.archlinux.org/title/SysVinit

Yes this form of dumb PIDFILE is used in Sysvinit.

Old historic PIDFILE system is very much blind faith if as in if a process still exists at PID value it must be the right process no need to perform any checks that it is the right process no need to record any extra information to make sure its the right process.

The historic PIDFILE is not in fact linked to /proc/$pid because the /proc directory did not exist when on any Unix was invented. All the historic PIDFILE is a file that you wrote a PID number into then in most implementations blindly trust yes this include sysvinit and many of the old alteratives.

Reason why systemd uses cgroups is so if a service first process starts another process cgroups track it yes of course the historic PIDFILE not going to track this.

In fact, not even pidfd_open or clone with CLONE_PIDFD can stop it.
Once it is waitpid/waitid on, it is recycled.

pidfd_open allows you to open a file handle then proceed to check /proc/$pid directory and if this matches what you are expecting then send terminate signal or equal. Now if termination happens in that window result was right process and signal sent the signal will not to go though to the replacement process. Yes one of the issues with PIDFILE usage is the fun case of killing the wrong process just because it was unlucky enough to start up on X PID value.

pidfd_open and signal commands is about allow create of a window to check if you have the right process. Of course the historic PIDFILE since they only contain PID value they don't contain any information to confirm that.

Lets say PIDFILE also did really include the time that the targeted PID started So instead of being "PID>PIDFILE" "PID mtime_of_/proc/$pid>PIDFILE" That enough information to check if something has been recycled or not under Linux. Because the /proc/$pid mtime does not change over a process life under Linux. Note that I wrote under Linux.

The big problem here there is no cross UNIX world standard to check if a PID has been recycled or not.

Systemd and launchd and SMF all needing platform particular code should start making sense as well.