On Tue, Jan 26, 2016 at 11:51:29AM +0000, Peter Duffy wrote:> I'm also still trying to figure out in what way systemd is supposed to > be "better". I've seen the following things claimed for it:Of the three things you list, hot-plug is certainly an important one. But, it's not the big deal. The big deal is that systemd is not just a fire-and-hope startup system, but a service manager. It knows which processes came from where. That means it can: * 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.) * 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.) * 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.) 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. -- Matthew Miller <mattdm at fedoraproject.org> Fedora Project Leader
> * 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
On Tue, Jan 26, 2016 at 04:20:39PM +0100, Sylvain CANOINE wrote:> Redhat employs Lennart Poettering. Redhat derivates have to follow.It is true that Red Hat employs Lennart. But, the rest is false. It's not the way Red Hat works, and it's not the way Fedora works. -- Matthew Miller <mattdm at fedoraproject.org> Fedora Project Leader
On Jan 26, 2016, at 8:20 AM, Sylvain CANOINE <sylvain.canoine at tv5monde.org> wrote:> >> * 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.What makes you think that having a supervisor makes you ignore problems? First off, a restarted daemon process is likely going to lose some kind of runtime state. Logged in users will be bounced out, work may be lost, etc. You will get calls about this. Second, it?s not like systemd invented this idea and is now trying to convince the rest of the world that it?s a good one. systemd was preceded by launchd, xinetd, inetd, Erlang supervisors? My company has prior art on that, for that matter, and I assure you, we don?t just ignore spontaneously restarting servers. All a supervisor does is replace human working time ? ?service badboy restart? ? with a tiny slice of computer time, reducing the impact of the downed service. If the daemon doesn?t immediately fail again, the total downtime charged against that daemon might be a fraction of a second. Yes, you still have to fix the underlying problem. But are you saying it would be better if your users were completely shut out while emails made their way through the tech support loop?> will just make GNU/linux more unstable.Then explain why Ericsson?s Erlang-based AXD301 telephone switching system achieved *nine* nines of uptime, in large part due to a supervisory process restarting framework: https://pragprog.com/articles/erlang If the supervisors were just restarting frequently-dying processes, don?t you think all the Ericsson based telephone systems in the world would be noticeably less reliable than, say, the AT&T ones?>> * 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.Well, in fact, mirroring logs to a trapdoor log server *is* a good security practice. It makes auditing a pwned system much less uncertain. I?m no huge systemd defender. It reeks of second system effects, god modules, and other antipatterns of software design. However, this is not the place to fix it or replace it. I?m here because I have no intention of fixing it or replacing it. Archimedes said he could move the world given a long enough lever and a firm place to stand. Maybe you think this mailing list is your lever of change, but you?ve forgotten that you also need a firm place to stand. All the force you put on that level will just push you out of position, rather than move your target. You need a firmer place to stand.