Not a "bloated, monolithic system"?

Posted Feb 4, 2019 19:08 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: Not a "bloated, monolithic system"? by jccleaver
Parent article: Systemd as tragedy

> Shell scripts can be complex. A 25 line shell script that just imperatively executes 20 commands and then exec's into a final daemon is not complex, and is in fact the simplest possible way to accomplish a deterministic goal on a *nix system.
Nope. How do you track the daemon state? Are you sure PID files are correct? How do you kill the daemon in case it's stuck? What if you want to allow unprivileged users to terminate the service? Do you need a separate SUID binary? ...

Writing a robust shell initscript is incredibly hard. It's not 25 lines of code, many initscripts are hundreds lines of code (and are still buggy as hell).

Not a "bloated, monolithic system"?

Posted Feb 4, 2019 19:20 UTC (Mon) by zblaxell (subscriber, #26385) [Link] (1 responses)

> How do you track the daemon state?

cgroups, watchdogs, service pings...

> Are you sure PID files are correct?

Don't use 'em, because cgroups.

> How do you kill the daemon in case it's stuck?

cgroups

> What if you want to allow unprivileged users to terminate the service?

We don't.

> Do you need a separate SUID binary?

No.

> Writing a robust shell initscript is incredibly hard.

No.

> It's not 25 lines of code, many initscripts are hundreds lines of code (and are still buggy as hell).

No.

Not a "bloated, monolithic system"?

Posted Feb 4, 2019 19:31 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> cgroups, watchdogs, service pings...
OK. Can you show me an init script that is 25 lines long AND uses cgroups to guaranteed the process termination?

During one of the systemd flamewars some years ago I tried to find an actual init script that uses cgroups for comparison with systemd units. I was not able to do it.

Writing it was also decidedly non-trivial, I had to create my own cgroup hierarchy convention and make sure that there are no race conditions in cgroups manipulation. Both are not easy at all, and I was not even trying to use cgroups controllers to limit the resource use.

Not a "bloated, monolithic system"?

Posted Feb 4, 2019 20:30 UTC (Mon) by jccleaver (guest, #127418) [Link] (2 responses)

> Nope. How do you track the daemon state? Are you sure PID files are correct? How do you kill the daemon in case it's stuck? What if you want to allow unprivileged users to terminate the service? Do you need a separate SUID binary? ...

The OP was concerned about doing dependency ordering, the 25 line script was not the init script itself.

> Writing a robust shell initscript is incredibly hard. It's not 25 lines of code, many initscripts are hundreds lines of code (and are still buggy as hell).

No, it's not. On RedHat systems it's this (which, other than the URL, has not changed since basically 2004 - EL3/EL4):

1) Cut/paste this: https://fedoraproject.org/wiki/EPEL:SysVInitScripts#Inits...
2) Edit primary process's name and path
3) Add any additional custom logic your daemon needs

If your initscript for a basic daemon has a more complex structure than this, then you're probably doing something wrong. If your distribution forces you to do something more complex than this, then I'm sorry for you.

Not a "bloated, monolithic system"?

Posted Feb 4, 2019 20:37 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> The OP was concerned about doing dependency ordering, the 25 line script was not the init script itself.
So now it's 25 lines for deps, then another 1k lines for cgroups manipulation in Bash.

Noted.

> No, it's not. On RedHat systems it's this (which, other than the URL, has not changed since basically 2004 - EL3/EL4)
Incorrect. This doesn't have PID file management, for starters.

RH /etc/init.d/functions tooling

Posted Feb 4, 2019 22:05 UTC (Mon) by jccleaver (guest, #127418) [Link]

> > The OP was concerned about doing dependency ordering, the 25 line script was not the init script itself.
> So now it's 25 lines for deps, then another 1k lines for cgroups manipulation in Bash. Noted.

cgroup *definition* is out of scope. To *assign* this process to a cgroup just set
CGROUP_DAEMON="cpu,memory:test1" (or whatever) in /etc/sysconfig/foo

> Incorrect. This doesn't have PID file management, for starters.

Incorrect. You can see in the start/stop sections that it's recommended to use the 'daemon' and 'killproc' functions, which handle PID file management for you and fall back to looking for the process's exec if not found. If your daemon does something weird in launch, you can have your daemon make the pidfile and pass that file name into the functions with -p.

The default 'status' function handles pid files automatically too.

All of this is in /etc/init.d/functions.
I'm sorry that you don't appear to be using a RedHat system, which is clearly the better distribution.