Debian May Be Leaning Towards Systemd Over Upstart

[peppepz]

Logging, for example - with classic sysvinit, the only way to get stdout/stderr output from a daemon was to shut it down, then manually run it in a terminal, passing extra parameters to stop it from backgrounding itself.

1) Aren't daemons supposed to use syslog for logging anyway?
2) /usr/sbin/my_daemon 2> /var/log/my_daemon.log & ? Can't I do this with sysvinit or whatever else?

Similarly, a proliferation of daemons with essentially the same function of starting other processes - init, inetd, crond, atd.

You could argue that the only function of the linux kernel is to start processes.
Furthermore, if 4 daemons, each one with limited and documented behaviour, are "a proliferation", what hyperbole will you use do describe the 538 files that make up my systemd installation?

It's easy to talk about UNIX philosophy and modularity, but what about the amount of redundant code covered by those four services?

The old-school answer is to factor the common code together by putting it into a common shared library. We already have a lot of those, and with systemd we have one more.

The fundamental feature of all of them is that they start processes and (potentially) trap the output and report it in some way - the only difference is a triggering event (system startup, a socket connection, or a scheduled time).

That's why you have multiple binaries that handle the different triggering event - because different events means different subsystems to interact with, different libraries to link in, different times to startup and lifetime cycles - and a single one that traps and reports its output, which is syslog.

Is merging some of them into a single service such a bad idea? Especially the latter two - there's really no good reason for having two separate daemons responsible for scheduled tasks, differing only on whether the tasks are recurring or one-off...

For example, with the old multiple binaries, if I want to stop internet-based services from getting automatically started, I stop inetd (or whatever else is playing its function), and I know that I'm done, because there's nothing hiding complexity from me.
With the new approach, I need to learn the commands to tell the new monolithic daemon to suspend socket activation, leaving local sockets alone, and to learn the commands again every time they change, or whenever I want to change the particular monolithic daemon that I use.

Which is not to say that merging atd and crond is not a good idea (is there any distribution that is still using atd and cron anyway?). An even better idea would be to standardize a format for a "startup recipe" that daemons writers can distribute with their code and expect it to run on any distribution. This would allow independent implementations of superservers with more freedom for users and developers. Also, competition leads to better code quality compared to monoculture.

Putting together atd, crond, syslogd, udev, dbus, connman into the same entity is an entirely different thing.

[RahulSundaram]

I've maintained my little Linux installation since the 90s. Systemd is too complex and undocumented for me, so once the Linux userspace begins depending on systemd, it's end of line for me. Linux is no different than OpenSolaris or Darwin if it becomes an opaque item that other people make for me and I use as-is.

That claim doesn't carry much merit. systemd is one of most extensively documented projects in Linux. From the homepage, here is a useful collection

• #1: Verifying Bootup
• #2: Which Service Owns Which Processes?
• #3: How Do I Convert A SysV Init Script Into A systemd Service File?
• #4: Killing Services
• #5: The Three Levels of "Off"
• #6: Changing Roots
• #7: The Blame Game
• #8: The New Configuration Files
• #9: On /etc/sysconfig and /etc/default
• #10: Instantiated Services
• #11: Converting inetd Services
• #12: Securing Your Services
• #13: Log and Service Status
• #14: The Self-Explanatory Boot
• #15: Watchdogs
• #16: Gettys on Serial Consoles (and Elsewhere)
• #17: Using the Journal
• #18: Managing Resources
• #19: Detecting Virtualization
• #20: Socket Activated Internet Services and OS Containers

• Manual Pages
• Tips And Tricks
• Frequently Asked Questions
• Debugging systemd Problems
• Incompatibilities with SysV/LSB
• Socket Activation with Popular Daemons
• Predictable Network Interface Names
• API File Systems
• Running Services After the Network is up
• My Service Can't Get Realtime!
• The 30 Biggest Myths about systemd

[GreatEmerald]

the (?) is for the units i don't know if call daemons or process or what

Either units or services.

1) Aren't daemons supposed to use syslog for logging anyway?
2) /usr/sbin/my_daemon 2> /var/log/my_daemon.log & ? Can't I do this with sysvinit or whatever else?

1) And what if they don't? You can't expect every program to behave correctly.
2) You can't, without sacrificing all of the things that make journald so good, like different log priorities (warn/error/debug etc.), filtering, unified timeline view (where all of the daemon messages are shown in one place in the order that they were emitted, including the messages from the init system itself), etc.

You could argue that the only function of the linux kernel is to start processes.
Furthermore, if 4 daemons, each one with limited and documented behaviour, are "a proliferation", what hyperbole will you use do describe the 538 files that make up my systemd installation?

You couldn't argue that. If anything, the main function of the kernel would be to control the hardware.
The 538 files have no redundancy between them. The 4 daemons do.

The old-school answer is to factor the common code together by putting it into a common shared library. We already have a lot of those, and with systemd we have one more.

Care to point out an example?

For example, with the old multiple binaries, if I want to stop internet-based services from getting automatically started, I stop inetd (or whatever else is playing its function), and I know that I'm done, because there's nothing hiding complexity from me.
With the new approach, I need to learn the commands to tell the new monolithic daemon to suspend socket activation, leaving local sockets alone, and to learn the commands again every time they change, or whenever I want to change the particular monolithic daemon that I use.

No. With the new approach, you issue systemctl disable network.target and carry on with your day. Or even better, disable the actual services that you don't want to boot, because otherwise you might accidentally stop a service you did want to boot after all. Stopping the inetd daemon is a horrible, hacky way of doing that and you should never even consider doing that as an option.

Which is not to say that merging atd and crond is not a good idea (is there any distribution that is still using atd and cron anyway?). An even better idea would be to standardize a format for a "startup recipe" that daemons writers can distribute with their code and expect it to run on any distribution.

And that's what unit files are about. They are supposed to be cross-distribution, and as far as I know there is nothing preventing other init systems from using them.

[Delgarde]

1) Aren't daemons supposed to use syslog for logging anyway?

Arguably, yes. But a) that doesn't mean they never write anything important to stdout/stderr, and b) not all daemons do so.

2) /usr/sbin/my_daemon 2> /var/log/my_daemon.log & ? Can't I do this with sysvinit or whatever else?

Now you've now created a persistent bash subshell that can't exit until the daemon does, something repeated for every single daemon you have running... a dozen processes that do nothing but accept the stderr output of another process and dump it to a file. And if the daemon does write it's normal logging to syslog, you've got two files containing disjointed logging output which you have to reconcile when hunting for errors, difficult if the stderr output lacks timestamps. Whereas by having both syslog and stdout/stderr output handled by the init service, having them merged into the same log is relatively trivial.

Furthermore, if 4 daemons, each one with limited and documented behaviour, are "a proliferation", what hyperbole will you use do describe the 538 files that make up my systemd installation?

No idea what that count includes (does that count config files?), but what's your point? I'm objecting to the idea of 4 daemons that do essentially the same thing - whereas presumably the 538 files you refer to don't.

With the new approach, I need to learn the commands to tell the new monolithic daemon to suspend socket activation, leaving local sockets alone, and to learn the commands again every time they change, or whenever I want to change the particular monolithic daemon that I use.

Eh, stuff changes, you learn new stuff. That's just the way the world works....

An even better idea would be to standardize a format for a "startup recipe" that daemons writers can distribute with their code and expect it to run on any distribution. This would allow independent implementations of superservers with more freedom for users and developers. Also, competition leads to better code quality compared to monoculture.

There's value in standards, no question - but you're talking about taking two existing systems that achieve similar results via wildly different processes, and trying to find some level of compatibility between them. The best possible outcome is that you end up with something so abstracted around the lowest common denominator as to be totally worthless...

Oh, and competition doesn't necessary lead to better code quality... often it's quite the opposite, since code quality isn't a strong selling point, and in a competitive environment, tends to get sacrificed in favour of rushing to deliver glamorous new features. Monocultures *can* be better, because they can be simpler - modularity comes at a high cost in integrating the different pieces, and even more so if those pieces can be swapped with others that may or may not conform to standards, and all of which have a different set of subtle bugs.

[Laser]

Even as only a "casual" system administrator (I run Arch, so I'm not a complete stranger to my systems' internals), I was amazed by the step from initscripts to systemd, because let's face it, sysvinit made sense back when you had large systems doing mainly one thing that didn't need much flexibility, so your tools weren't neither. Your system booted, got network (or so you hoped) and then started its daemons regardless of what happened until then and pray to god the chain was set up correctly (slight overexaggeration). Then every daemon behaved like the developers thought is right. Forking, double-forking, managing the process via PID... all this required a carefully set up collection of tools that depended on the administrator doing all the work by hand. Nowadays, all this has become a breeze. Manage your services? A unified command set will assist you. Search the logs? No more grepping with complicated regexps (worst case). journalctl knows more about the system than you ever could (like what happened since this boot, since x minutes, which services failed when and how...) Debug a starting system? Nigh impossible with sysvinit when unlucky. systemd? A breeze. Why does my system take so long to boot? Good luck scraping through the various log files with sysvinitl and calculate what happened. Meanwhile, systemd-analyze blame just knows. A service is misconfigured and hard to control? systemd's cgroup support got you covered - sysvinit not so much. Socket-based activation easily manageable? systemd can do that. And we haven't talked about boot time yet, which is just another side effect of the fact that the system is just well thought-through and starts stuff intelligently instead of how the admin set it up once, even though systems nowadays can change pretty often - think virtual servers. That said, you can set up systemd so it is aware of the fact it is running inside a container so it can reuse the needed services provided by the hosting system - if you so choose (IIRC, I haven't used this one myself yet).

If you want to continue using shell scripts to start your system, go ahead! But I guarantee you, once you have actually done work with systemd, you will never want to return to initscripts. Worlds seperate them.

[JX8p]

Wait, just to clarify before i go ahead and add you to ignore... Your immediate and top problem with systemd is its original author?

You may wish to read again. I am specifically railing against arguments based purely on the person. My immediate and top problems with systemd include journald's logging format and the sheer size of the codebase.

[Alejandro Nova]

I don't think Attent?ter was implying it was a problem. Many of the political arguments against systemd are usually formulated somewhat like this: 'Lennart Poettering is the devil, systemd is of Lennart Pottering, therefore systemd is of the devil'. A variation on this theme would consist of substituting 'Red Hat' for 'Lennart Poettering'. I think Attent?ter was trying to counteract that prejudice. But it isn't for me to speak for Attent?ter, so I'll leave it here.

And PulseAudio. You can't forget about PulseAudio if you want to troll correctly. It doesn't matter that your computer sounds marvelously, that you have access to better resample algorithms than what your sound card has, that you can auto mute your sound when your phone gets a call, or that you can switch your sound between two sound cards with a simple command/GUI order; if facts get in the way of a prompt conclussion, they can be discarded.

So, the argument goes this way: PulseAudio (0.~.x) broke my computer. PulseAudio was made by Lennart Poettering. All software by Lennart Poettering breaks computers. systemd is made by Lennart Poettering. systemd (Syst?me D for purists and more advanced trolls) breaks computers because it's made by Lennart Poettering. Lennart Poettering is set on a conspiracy set up by Red Hat to break every single Linux desktop and server, because he is the devil.

We've seen a lot of that through this thread.

[JX8p]

Systemd as Debian's new init-system of choice has probably just been dealt its fatal blow as upstart is preliminarily working with kFreeBSD. Given the immature refusal of Poettering to even accept any patches allowing systemd to run on other platforms, which is vulgarly defiant of Debian's stated aims, one assumes they will be leaning towards upstart once more.

And thank goodness I say. Software monoculture is a trend that the FOSS community has been moving to, under the weight of Red Hat and their ilk. Someone needs to say no to this.

[c117152]

The point is that it wouldn't be worth it for THEM.

Yap. This isn't some sexy little project folks do to scratch an itch. Inits are critical functionality mid-level plumbing that can't be hacked up over a weekend. That's why it took Apple to bring up the idea and Ubuntu and Red Hat to pick up on it for linux.

Worse, there are already good enough, or better (arguably, depending on your position in this debate) alternatives. So a paid dev might be willing to duplicate someone else's effort or sign his work away, but those contributors and volunteers? Nah... Ain't gonna happen.

p.s.

https://www.youtube.com/watch?v=Pk7yqlTMvp8

[Akka]

Systemd as Debian's new init-system of choice has probably just been dealt its fatal blow as upstart is preliminarily working with kFreeBSD. Given the immature refusal of Poettering to even accept any patches allowing systemd to run on other platforms, which is vulgarly defiant of Debian's stated aims, one assumes they will be leaning towards upstart once more.

And thank goodness I say. Software monoculture is a trend that the FOSS community has been moving to, under the weight of Red Hat and their ilk. Someone needs to say no to this.

Still zera members in the commite without canonical connections support upstart at the moment. To me its look like 4 support systemd 3 upstart and one of them has not jet said anything.