Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[gamerk2]

This whole thread highlights the downside to Linux: Configuration hell.

And before you say anything, ask the somewhat obvious question: Why should the Kernel care about Systemd?

/sys/fs/cgroup is rwx for root and r-x for all others for me, same as systemd's subdirectories. Only files user-writable in there are some symlinks, so I'm not sure what you're talking about.

---

$ mount

......
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
.....

Like I said, it's read only mounted fs, your permissions aint gonna be worth anything in this case.

[gens]

That was my point, althought it seems this kind of irony does not translate well to English :-P

the irony is you don't need to patch the service with systemd specific anything

also not systemd, nor anything that was not written specifically to check if a service is running properly can know if a service is running properly
i'd say more on this problem but i feel the audience would not care

bdw;
even SIGSEGV can be handled by the process that got it
and a process can rexec itself with only minor annoyances (setting up sig handlers again)
think about it

[Nobu]

/sys/fs/cgroup is rwx for root and r-x for all others for me, same as systemd's subdirectories. Only files user-writable in there are some symlinks, so I'm not sure what you're talking about.

Regardless, he's already written about it, and I'm not going to argue about something I don't understand well.

systemd will know it crashed because it keeps track using cgroups, before somebody asks. This is completely unrelated to the service, and no configuration or patching is required for this to work.

Yup, sounds like a nice functionality, but they also managed to break userspace with it, since this can't be normally disabled and systemd mounts "/sys/fs/cgroup/" as "ro" tmpfs (read only), while it also mounts it's own subdirectories as "rw".
This effectively break userspace stuff like ulatencyd or custom scripts around jails used by hosting.

[doom_Oo7]

That was my point, althought it seems this kind of irony does not translate well to English :-P

[Nobu]

systemd will know it crashed because it keeps track using cgroups, before somebody asks. This is completely unrelated to the service, and no configuration or patching is required for this to work.

[Nobu]

Ans how do you stop dependant services if the one they depend on cranes and you don't know it due to lack of tracking?

If you use systemd, then you can configure it to automatically kill those processes, or allow them to continue running. If you use some other service manager, then it depends.

Or, if you were talking about separate services altogether, whether those services are stopped or not depends on whether you add the depending services to Wants or Requires in the dependent service, or the other which way...I'm dyslexic, okay?

[doom_Oo7]

this has nothing to do with dependency handling
dependency handling is in .service files (in systemd-s case)

Ans how do you stop dependant services if the one they depend on cranes and you don't know it due to lack of tracking?

[gens]

Except without dependency handling and without tracking of child processes. You know this, it has been explained to you dozens of times.

this has nothing to do with dependency handling
dependency handling is in .service files (in systemd-s case)