BUS1 Working On "r-linux" - A Rust Capability-Based Linux Runtime

[coder]

Coder you started saying things that are not based on facts.

I suppose that means I'll join you, in that regard.

[sinepgib]

There is a problem. https://www.baeldung.com/linux/pid-file yes person wrote this in 2021 and its wrong. Guess what .PID files don't work correctly on Linux and did not even in 0.1 Linux kernel this is a day 1 design issue.

https://securitylab.github.com/research/ubuntu-apport-CVE-2019-15790/

Its covered in this security bug. Linux kernel does PID recycling. POSIX standard for writing scripts presumes PID will not be recycled. This is why POSIX standard for scripts has putting PID value into .pid file as a valid action. Reality pid value in a .pid file is to be totally no trusted without some means of secondary checking. Secondary checking does the PID own to the correct cgroup of course that means you had created cgroups when you started the service.

The reality is posix standard script does not include anything for processing tracking that in fact works correctly with the Linux kernel. PID value shoved into a .pid file works on many Unixs due to restrictions on PID recycling. Now PID tree issues of Linix I could give security bugs on that. Yes so you terminate pid of a service you only kill part off it as part of it as disconnected it self from the pid tree so no longer look like it was started by the service.

My posts have started pid issues and pid tree issue over and over again. PID recycling feature of Linux has lots of dangers this is the PID problem. The means to remove relationship between two PIDs that Linux supports the PID tree breaking feature also has lots of dangers this is the PID tree problem.

You restrict yourself to either the POSIX define API for C or the POSIX define shell script language you find yourself unable to correctly manage services under the Linux kernel. We are talking over 5000+ documented CVE here effecting lots of different services. Yes there code presumes Linux kernel in Posix conformance when the Linux kernel is not resulting in a security bug.

At some point you have to admit up to the Linux kernel issue. Shell neutrality claim people make fail to see that they have tied their hands to the point they cannot manage services safely on Linux. How do you get cgroup information on process using posix only shell features the answer is you don't.

How do you use the pidfd interface from posix shell limited features to prevent PID recycling messing with your actions again you you cannot. Something interesting is freebsd init system yes is written is shell script but they have not limited themselves to Posix shell script features because their init shell scripts can use "process file descriptors". So be it Linux or freebsd you are stuffed doing process management if you restrict yourself to Posix shell features or Posix C API features. Remember both linux and freebsd have PID recycling.

https://bug-bash.gnu.narkive.com/qmN6b7Dk/aix-and-interix-also-do-early-pid-recycling

The nightmare here is the PID recycling problems that Posix shell script does not deal with is not Linux or Freebsd exclusive problem. This problem effects operating systems that are formally branded Unix. The reality here Posix shell or C API defined interfaces are not good enough for service management and has not been for decades.

People forgot that early Unix never recycled PID values instead once you allocated the last PID value the system just crashed and POSIX standards fairly much still presume this is case and have never been evolved to deal with correctly with any kernel that recycles PID values. How many more CVE do we have to have before people accept the POSIX method does not work correctly and has to be replaced.

Not gonna read it all, the first phrase is enough to see you think I am defending the use of boot scripts when I am not. I said one thing and only one, and that is iff you go for scripts, the choice of POSIX is about picking your shell. It's specially important for Debian that needed to migrare from Bash to Dash due to slow boot times. Of course, the real solution to slow boots is parallelism and avoiding the shell altogether.

[oiaohm]

I suppose that means I'll join you, in that regard.

How with the defects of the Linux PID system has Gnome/KDE/XFCE/X11 DE session management worked correctly prior to systemd?

Next question who was the party that first made solution that made service management or session management that could in fact work correctly with the Limitations of the Linux kernels PID system?

What is the name of the project where the first functional correct service management/session management solution was made?

Come on now coder answer those questions.

Funny part with these fundamental problems. Not handling PID/PID tree reality of Linux is no different to using a hammer to drive in screw it kind of works. Problem is a person who has seen a screw driven in with a screw driver knows it will hold better. So has no interest in support solutions that are not equal to a screwdriver so not support solution as bad as hammer. Basically coder does not want to admit Redhat dominance is purely caused by lack of working alternatives.

Final question how many solutions exist today that are fully implemented to do session management/service management under Linux correctly?

The last one is important the answer is very horrible. Coder what would you do if that last question turns out to be only 1? What if the problem appearance reducing diversity and the changes is because there was no real functional correct solution diversity for Linux in the first place?

[coder]

Come on now coder answer those questions.

I think I've made it abundantly clear that I have no intention of playing your game. At this point, you're just spamming the forum.

On the plus side, it makes your agenda that much more transparent.

[oiaohm]

Not gonna read it all, the first phrase is enough to see you think I am defending the use of boot scripts when I am not. I said one thing and only one, and that is iff you go for scripts, the choice of POSIX is about picking your shell. It's specially important for Debian that needed to migrare from Bash to Dash due to slow boot times. Of course, the real solution to slow boots is parallelism and avoiding the shell altogether.

The horrible part here is early systemd was slower in parallelism than modified sysvinit with dash. Yet debian still goes systemd at the time.

https://superuser.com/questions/6026...this-even-work
Welcome to a funny reality. Systemd was more power effective with early debian than sysvinit even that it was slightly slower.

So sorry sinepgib you just stated a commonly believed myth that systemd and upstart was about improvement boot speed by improving parallelism. The reality here is systemd and upstart in fact has less parallelism than the old modified for parallelism sysvinit solution but it also has less CPU time wasted spinning on stuff.

Yes there was a performance gain using dash over bash interest enough that less than the overhead early systemd overhead trying to use cgroups to cover for what is now done by PIDFD and the overheads of using cgroupv1. Yes there are some quite horrible overheads dealing with cgroupv1 defects.

Early Systemd is slightly slower boot but a more power effective boot and closer proper service management that works with the way the Linux kernel treats PID values and PID trees.. Of course systemd overhead drops over time as the kernel side improves with cgroupv2 and pidfd.

Its a surprise to some people that systemd does in fact give up some boot performance so that service management can work correctly. Defective service management even defective service management writing in shell script can be faster than systemd at starting the system up. Please note reporting that services are up correctly and being able to correctly stop/restart services all the time goes out the window with defective service management so making system issue diagnostic in production more time costly..

sinepgib good question what one is more important. Boot speed/Parallelism vs Production service management providing correct information on service status and correctly stopping/starting and restarting services?

Something I do find really annoying there is not command line tools using pidfd functions to perform tasks from shell scripts. Think about it a pidfdkill program that you are able to pidfdkill PIDnumber cgroup,,,,(list of other details to confirm target). This would allow you from script to exactly kill a target under Linux instead risking some random passing process that happened to take the PID number.

https://pubs.opengroup.org/onlinepub...ties/kill.html

Notice the kill command is in the posix standard for shell usage and it does not work correctly on systems that can recycle PID numbers. Yes the ps command again posix by the time you get the information and use the information it can be out of date. What the objective of pidfd is to make sure that if you are acting on out of date information to kill a PID nothing get killed because it knows it out of date information and that the PID died/crashed before you got around to attempting to send it the kill command. Note some other process can have taken over that PID number by that point..

sinepgib the issue here is once you truly look maybe you don't want to start your services using bash/dash any more. Or at least you should be after some replacements to the common usage of kill and ps in you service management scripts because they don't work correctly with the Linux kernel and don't in fact work correctly with freebsd and many other kernels. Yes lot of Unix and Unix like operating systems have provide their own alternatives like pidfd because of the same fundamental problem. Yet people keep on writing service start up scripts with these fundamental problems.

[oiaohm]

I think I've made it abundantly clear that I have no intention of playing your game. At this point, you're just spamming the forum.

On the plus side, it makes your agenda that much more transparent.

Next question who was the party that first made solution that made service management or session management that could in fact work correctly with the Limitations of the Linux kernels PID system?

What is the name of the project where the first functional correct service management/session management solution was made?

Come on now coder answer those questions.

Final question how many solutions exist today that are fully implemented to do session management/service management under Linux correctly?

The last one is important the answer is very horrible. Coder what would you do if that last question turns out to be only 1? What if the problem appearance reducing diversity and the changes is because there was no real functional correct solution diversity for Linux in the first place?

No the party that upvoted you need to read back and notice you moved the goal post and to answer these questions themselves.

What I'd rather see is open standards and open implementations, like we had with X11 and POSIX. Or, at the very least, maybe trying to establish solutions more by creating an ecosystem, rather than developing their own internal projects which they subsequently entrench via their dominant market position.

Do note you X11 and POSIX standard was created after the fact and you used that as excuse as well why POSIX is bad. Then you use W3C and. Khronos group.

Please note every one of the open standards vendor implements first make standard latter after vendor has worked out how it should work. Mozilla, Microsoft Google to W3C do their only implementations first before submitting to standard with W3C. Khronos group all your GPU vendors. Posix same thing all your Unix vendors implement their side first then submit to POSIX standard. X11 Protocol implement first then submit to X11 Protocol for approval.

Yet you were here in that past post asking redhat to do the the reverse to normal coder.

Extra question coder who is the standard body to submit system service management solutions to? Guess did exist in the Linux Standard Base that died because people would create init scripts not conforming to Linux Standard Base standards so what was point of having a standard for this.

Coder the reality you don't want to get into this arguement because none of your points were ever right. Linux is no more monolithic or less standardised than it ever was. Maybe this is area were we need todo better. The real state is more in face now that redhat has taken many projects they had 100 percent control over anyhow since 1995 and put them under 1 project called systemd. Its no different to 50+ shell companies displaying themselves as a single company.

Coder the history here totally horrible. Ways people claim it has changed it has not. Init and service management systems have almost always been in the Linux world chosen by survival of the most common. The most common has mostly been decided by the commercial distributions since 1995.

[coder]

No the party that upvoted you need to read back and notice you moved the goal post and to answer these questions themselves.

You're starting to be abusive. Don't cross the line or your posts might start getting flagged.

[oiaohm]

You're starting to be abusive. Don't cross the line or your posts might start getting flagged.

How with the defects of the Linux PID system has Gnome/KDE/XFCE/X11 DE session management worked correctly prior to systemd?

Next question who was the party that first made solution that made service management or session management that could in fact work correctly with the Limitations of the Linux kernels PID system?

What is the name of the project where the first functional correct service management/session management solution was made?

Final question how many solutions exist today that are fully implemented to do session management/service management under Linux correctly?

The last one is important the answer is very horrible. Coder what would you do if that last question turns out to be only 1? What if the problem appearance reducing diversity and the changes is because there was no real functional correct solution diversity for Linux in the first place?

Extra question coder who is the standard body to submit system service management solutions to?

Answer the questions Coder. Once you answer the questions you will work out that Redhat had no choice. Ubuntu starting upstart was because of the PID and the PID tree issues of Linux kernel yes canonical also had no choice. Keeping solution that causing CVE after CVE after CVE cannot go on forever.

All major open source standards are developed after a functional implementation already exists

sinepgib and others had the incorrect idea that systemd was about bootspeed. Yes people selling system sold boot speed but the real tests of systemd done by core debian and ubuntu maintainer in their compare of init before changing to systemd in fact found systemd is slightly slower other distributions found the same thing. That brings a question if systemd is not faster why did so many distributions decide to change to systemd for real. The answer like it or not is what I am point at coder.

Why is Linux at the moment coming so systemd monolithic. There are a stack of areas that were also being effected by the same problem. CVE for PID recycling caused issues.

https://saelo.github.io/presentation...st_the_pid.pdf The PID recycling issue is not restricted to Linux. This a presentation for OS X. I could find presentations for all kinds of posix compatible solutions. Every time the correct solution to fix PID recycling issue is use kernel particular code cease being a generic code base that works every where.

Coder don't try moving the goal posts to another topic. The reality to take the debate forwards you need to know the answers to the questions I am asking. Also you need to accept there is a fundamental problem that comes from POSIX around process handling. Yes every Unix and Unix like OS with PID recycling support is effected by this problem. Every Unix and Unix like OS with PID recycling has not used a generic solution to solve this problem. Unique to kernel design solution in every case.

Yes the fundamental problem is why KDE and Gnome had to find different session management solution to what they were using.

Coder the Linux environment userspace coming in short term more monolithic is simple side effect of finally parties stopping sweeping the fundamental problems of POSIX under rug and ignoring them.

Coder big thing here major problem effecting all POSIX based OS with PID recycling that the POSIX standard group is doing nothing about. There is a true bad organisation here that has been driving fragmentation and defective solutions.

Remember POSIX is made after the fact. Yet people mandate you make scripts conforming to POSIX standard limitations without any consideration if the POSIX standard is correct. Getting POSIX standard changed to fix these issues would take effort. Remember you have a hurding cats problem here where all the different posix systems have already gone different directions.

POSIX is key part of problem that caused Linux userspace excessively fragmented. Once one party decided to go hey we will make a solution that not limited by posix limitations and try to fix the problem is what leads to systemd and once that is created area after area that people had attempted over and again to make work while being cross platform parties have gone why in hell are we doing this.

Coder you need to take off your rose colour glasses look back and see how a fundamental problem leads to Init, service management and session management fragmentation because end users where hitting problems. Yes coding to scratch itch problem was these people were coding without knowing exactly what the itch was causing them problems or knew what the itch was and found a worse problem with the method they tried to use to fix it. Systemd comes along and developer here finally solves it for the Linux kernel. Problem that puts people noise out of joint is that this is a kernel unique solution and lots of code needs to be updated no longer to depend on PID values alone.

Coder this is another question how do you fix the PID recycling problem without breaking compatibility with service management solutions that are still using PID as their only ID system? The answer is a horrible you cannot.

Redhat in reality is trying to remove the PID recycling problem from Linux. Redhat has the funding and resources to-do this. This is exactly like the old saying you cannot make a omelette without breaking a few eggs. Yes the PID recycling and PID tree problems have to be solved to stop future CVE from happening.

The reality here we need a higher min standard of what is classed as acceptable in service management and session management. Mind you we most likely would not require this higher min standard if POSIX standard was not defective.

[coder]

...

What do you think you gain by this? Nobody is reading it. It's functionally equivalent to spam.

[sinepgib]

The horrible part here is early systemd was slower in parallelism than modified sysvinit with dash. Yet debian still goes systemd at the time.

https://superuser.com/questions/6026...this-even-work
Welcome to a funny reality. Systemd was more power effective with early debian than sysvinit even that it was slightly slower.

So sorry sinepgib you just stated a commonly believed myth that systemd and upstart was about improvement boot speed by improving parallelism. The reality here is systemd and upstart in fact has less parallelism than the old modified for parallelism sysvinit solution but it also has less CPU time wasted spinning on stuff.

Yes there was a performance gain using dash over bash interest enough that less than the overhead early systemd overhead trying to use cgroups to cover for what is now done by PIDFD and the overheads of using cgroupv1. Yes there are some quite horrible overheads dealing with cgroupv1 defects.

Early Systemd is slightly slower boot but a more power effective boot and closer proper service management that works with the way the Linux kernel treats PID values and PID trees.. Of course systemd overhead drops over time as the kernel side improves with cgroupv2 and pidfd.

Its a surprise to some people that systemd does in fact give up some boot performance so that service management can work correctly. Defective service management even defective service management writing in shell script can be faster than systemd at starting the system up. Please note reporting that services are up correctly and being able to correctly stop/restart services all the time goes out the window with defective service management so making system issue diagnostic in production more time costly..

sinepgib good question what one is more important. Boot speed/Parallelism vs Production service management providing correct information on service status and correctly stopping/starting and restarting services?

Something I do find really annoying there is not command line tools using pidfd functions to perform tasks from shell scripts. Think about it a pidfdkill program that you are able to pidfdkill PIDnumber cgroup,,,,(list of other details to confirm target). This would allow you from script to exactly kill a target under Linux instead risking some random passing process that happened to take the PID number.

https://pubs.opengroup.org/onlinepub...ties/kill.html

Notice the kill command is in the posix standard for shell usage and it does not work correctly on systems that can recycle PID numbers. Yes the ps command again posix by the time you get the information and use the information it can be out of date. What the objective of pidfd is to make sure that if you are acting on out of date information to kill a PID nothing get killed because it knows it out of date information and that the PID died/crashed before you got around to attempting to send it the kill command. Note some other process can have taken over that PID number by that point..

sinepgib the issue here is once you truly look maybe you don't want to start your services using bash/dash any more. Or at least you should be after some replacements to the common usage of kill and ps in you service management scripts because they don't work correctly with the Linux kernel and don't in fact work correctly with freebsd and many other kernels. Yes lot of Unix and Unix like operating systems have provide their own alternatives like pidfd because of the same fundamental problem. Yet people keep on writing service start up scripts with these fundamental problems.

You're wrong again. For someone who expects people to read walls of text you do read too little of the short comments I posted. Did I mention systemd? Did I oppose systemd? Did I say shells are a good idea for init? Nope. Never. I corrected one claim about the reasons some people fret over shell scripts being POSIX. No more, no less. I said not that this is why systemd exists, as I am fully aware sysvinit was broken. What I implied is a fact: parallelism is better for starting many independent services (or with clusters of dependencies) performance wise than sequential startup, and shells add massive overhead, specially if the actual service is quick to start. Whether initial versions of systemd beat a patched up sysvinit is entirely irrelevant to the claim.
Don't look for subtexts where there are none, that's a paranoid trait my friend.