> * insure that when something is stopped, it's actually stopped. (If
> you've ever managed an HPC cluster and had processes escape the
> scheduler, you know this problem is real.)
# systemctl list-units | grep -c abandoned
453
# uptime
15:53:58 up 11 days, 21:03, 1 user, load average, 0,01, 0,02, 0,05
>
> * track process lifecycle, and restart (or take other action) on
> failure. (If software were perfect, this wouldn't be needed, but as
> is, this can save you being paged in the middle of the night.)
No. A software which falls down is buggy, and needs to be fixed. Period.
Masking the problem is the best way to never fix it. With this "feature", systemd (and other init systems providing it) will just make GNU/linux more unstable.
>
> * actually securely connect output to the process it came from for
> logging -- both stdout/stderr and actual log messages. (This is why
> journald is closely integrated.)
Driving sysadmins unable to read logs just because the file is corrupted, or to send logs to a dedicated server, is a real security improvement, indeed.
>
> There are other advantages (real dependency ordering, resource
> management/reservation with cgroups, etc.), but process supervision is
> the big deal. There are other alternative systems which _also_ do this,
> but overall, Fedora, openSUSE, Arch, Debian, Ubuntu, and others
> eventually decided that systemd was the technically best choice.
Redhat employs Lennart Poettering. Redhat derivates have to follow.
Ubuntu and Debian choose systemd, on one hand, because more and more softs depend on systemd (Gnome 3, for example), and on the other hand, to save maintainers time, dropping their own init system.
The technically best choice, you say ?
Sylvain.
Pensez ENVIRONNEMENT : n'imprimer que si ncessaire
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
