Ubuntu To Switch To systemd

GuerillaRadio writes "Following the decision for Debian to switch to the systemd init system, Ubuntu founder and SABDFL Mark Shuttleworth has posted a blog entry indicating that Ubuntu will now follow in this decision. 'Nevertheless, the decision is for systemd, and given that Ubuntu is quite centrally a member of the Debian family, that's a decision we support. I will ask members of the Ubuntu community to help to implement this decision efficiently, bringing systemd into both Debian and Ubuntu safely and expeditiously.'"

Comments

Good...?

[Kagetsuki]

I think it's good Shuttleworth was able to suck up his pride and go along with this decision to prevent fragmentation. I do however call the original decision slightly into question, but that's only because I've gotten sort of used to upstart. Hopefully anything good that was implemented in upstart but was not in systemd will make its way over.

Re:Good...?

[fishybell]

Having switched from System V to upstart to systemd I can safely say that yes, systemd is better for a full server or desktop OS. It has better reporting tools, it has more fine grained control, and it's fast. The trade off is complexity and size. There are many computer systems that the cost of switching to systemd will not bear fruit for a very long time (ex. embedded), but for servers and desktops that time has arrived.

Learn to love systemd; it's here to stay and for good reason.

Re:Good...?

[serviscope_minor]

Can you enlighten us?

Mostly, unless I've needed to hack something I've ignored the init system more or less completely. SYSV seemed to work OK (never noticed any obvious problems) and on Arch it used to be really rather fast to boot as well.

I genuinely do not know what is bad about wrong with SYSV and what is better about systemd.

There seems to be a lot of hot air in general and people arguing from a point of ignorance. You seem to have looked into it. What's the beef?

Re:Good...?

[baffle]

From what I've read about systemd it seems like a better system, and it sure helps with the fragmentation situation. Hopefully RH/Canonical can decide on Wayland vs Mir as well..

Re:Good...?

[Anonymous Coward]

Having switched from System V to upstart to systemd I can safely say that yes, systemd is better for a full server or desktop OS. It has better reporting tools, it has more fine grained control, and it's fast. The trade off is complexity and size. There are many computer systems that the cost of switching to systemd will not bear fruit for a very long time (ex. embedded), but for servers and desktops that time has arrived.

Learn to love systemd; it's here to stay and for good reason.

I understand that better reporting tools are a good thing (can you explain more to those of us who haven't migrated?). But otherwise, it's an init system. Just how often are you rebooting that server?

Re:Good...?

[robmv]

Jolla Sailfish OS use systemd

Re:Good...?

[s.petry]

I am with you, I never saw a reason to get rid of SYSV. The reason Linux started pushing is based on the same Logic Sun had to go away from it. A master daemon which monitors all services and their current states, restart when necessary, etc... The Sun implementation took a bit of getting used to, but in reality the daemon used XML files which contained mostly SH scripts. It was still hackable, which is why SYSV stuck around for so long. When something does not work, write a new SH script and stick it in init.

The Linux implementation is not as straight forward as Sun's implementation which to me says a lot. RH6 went to systemd and I hated it. Cryptic, not hackable, and simply a pain in the ass to customize unless you run everything in legacy mode which is still SYSV. The alleged better logging did not exist, and was much harder to access than "set -x" in an init script.

The overlord daemon is an advantage, previously we all used monitoring scripts to do things for us. The system now has it built in. I never saw an issue with writing restart options into BigBrother, Nagios, etc.. so don't save much with this small feature. In the grand scheme of things, I lose a lot of flexibility with this system. So most of my custom tools, code, and scripts will run in legacy mode.

Re:Good...?

[Anonymous Coward]

RH6 uses upstart.

Re:Good...?

[Anonymous Coward]

As a sysadmin, the complexity in creating a random startup script for a new custom service on a systemd server is a huge barrier to entry.

Re:Good...?

[fishybell]

System V has a scrict sense of a run level. For example, if you want a full desktop, run level 5 is often used, for a headless server, run level 3. What if you have a box that is headless most of the time, but you want to be able to run a full desktop sometimes? With System V you would change from run level 3 to run level 5 which would, depending on implimentation, stop and start services that are needed by both. Systemd instead has the concept of targets. Your full desktop target would have the headless server target as a dependency, and starting the full desktop would only run what isn't already running. You typically also have individual sevices that have dependencies. For example, you'd want your dhcp server to wait to start until the network has come online. In System V you have to define network as a number and make sure everything that depends on it has a bigger number and everything it depends on to have a smaller number. systemd's dependency model is also smart enough to start processes in parallel.

All of that is just the most exposed part of systemd (to me at least). It also supplants other processes such as xinetd and udev. Instead of having three different ways to start processes based on system events (startup, port connection, hardware event) you have a single system to manage all three. It can get complicated (wasn't udev already complicated?) but the consistency is worth it.

To keep all the consitency systemd provides a series of functions and magic variables. By magic variables I mean you set a list dependencies, which IMHO is less magic than the chkconfig comment lines in a typical System V init script. Both the magic variables and functions mean your typical service initaliation script is 10 lines instead of 100. While they may not be as obvious what's going on (a System V script is self-contained and can be ran on it's own) it is once you've become familiar with them.

Re:Good...?

[Anonymous Coward]

RHEL6 may use upstart (though I doubt it) RH6 (releases 26 April 1999) used SysV Init.

Re:Good...?

[X0563511]

CentOS 6 doesn't. I know Centos doesn't track RHEL 100%, but that's a significant difference...

Re:Good...?

[fishybell]

In truth, like System V, it's a set it and forget it sort of thing for most users (or more realistic, never realize it's even there sort of thing). For me, I have about 40 servers, physical and virtual, and about 150 thin clients to manage using various shades of Fedora, CentOS and RHEL. The thin clients boot over pxe to and then connect via xdmcp to a Fedora 19 box for their desktop environment. As Fedora 19 isn't exactly the best, and users do strange things, one will end up getting rebooted every week or so. The thin clients end up getting rebooted all the time (people think they should turn off their computer at night, so they do). Being able to use journalctl to see exactly what process took how much time was instrumental in getting a fast bootup time, which makes users happier. Happy users = happy admin. Happy admin = the building doesn't get burned down in a quest to get back the stapler. Every time I have to mess with anything other than systemd (on the CentOS and RHEL servers) I die a little inside. It's like using ipchains instead of iptables. Yes it worked, but the world moved on (and yes, I know, iptables is archaic at this point in time).

Re:Good...?

[Eunuchswear]

Having switched from System V to upstart to systemd I can safely say that yes, systemd is better for a full server or desktop OS. It has better reporting tools, it has more fine grained control, and it's fast. The trade off is complexity and size. There are many computer systems that the cost of switching to systemd will not bear fruit for a very long time (ex. embedded), but for servers and desktops that time has arrived.

Learn to love systemd; it's here to stay and for good reason.

My phone uses systemd. It seems to work.

Re:Good...?

[caseih]

RH6 went to systemd? I don't see systemd on any of my RHEL6 or CentOS6 machines.

I am running a RHEL7 beta box, and it does have systemd. And it's not really that cryptic or unhackable. In fact getting a new daemon installed and running is far simpler than with sysv. You don't have to write an init script. Just create a simple ini file, and away it goes. Because there's no init script to screw up, things are easier to debug. If you can run the daemon from the command line and it's happy, then you know it will work with systemd. And the logging facility is much better since the daemon can just write to standard out or standard err if it wants to, and everything is captured to the log (and normal syslog still works).

Yes if you resist working with Systemd, and work against it, your life is going to be a lot more difficult. And I used to think as you do about it, but after working with it a bit more, I can see how it is a better system. It's still too opaque for my tastes, but in practice it works very well.

My only concern is how deeply it ties into the Linux Kernel, which means that we're losing the freedom to use other Unix operating systems once we tie to systemd. Competition is always good but this is going to really squeeze FreeBSD (and to a lesser extend OpenBSD). Gnome 3 is Linux only because of this. We'll have to see where this goes I guess.

Re:Good...?

[inhuman_4]

not bear fruit for a very long time (ex. embedded)

Don't be so quick to count embedded guys out yet. While there isn't much in systemd itself, but as I understand it it will integrate well with kdbus. And kdbus (I think) plans to support QNX style "yield CPU to destination" type message passing. Which is a very nice feature for realtime systems.

Re:Good...?

[Anonymous Coward]

Here is a forum post that explains some of the reasons Arch Linux switched. Obviously, not all of these reasons are important to everyone. And maybe none of them are important to you. But there definitely are reasons.

https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

Re:Good...?

[Kremmy]

The tradeoff is complexity and size. I've got to say, I still don't buy it, this entire concept of requiring more resources to do the same job and yet somehow being more scalable to a degree that makes the trade-off worthwhile. If you have to upgrade your system to see the benefits (embedded systems are no slouches these days, look at any ARM tablet specs) then those benefits are seriously questionable.

Re:Good...?

[kthreadd]

Really? Wikipedia says otherwise.

Re:Good...?

[causality]

In truth, like System V, it's a set it and forget it sort of thing for most users (or more realistic, never realize it's even there sort of thing). For me, I have about 40 servers, physical and virtual, and about 150 thin clients to manage using various shades of Fedora, CentOS and RHEL. The thin clients boot over pxe to and then connect via xdmcp to a Fedora 19 box for their desktop environment. As Fedora 19 isn't exactly the best, and users do strange things, one will end up getting rebooted every week or so. The thin clients end up getting rebooted all the time (people think they should turn off their computer at night, so they do). Being able to use journalctl to see exactly what process took how much time was instrumental in getting a fast bootup time, which makes users happier. Happy users = happy admin. Happy admin = the building doesn't get burned down in a quest to get back the stapler. Every time I have to mess with anything other than systemd (on the CentOS and RHEL servers) I die a little inside. It's like using ipchains instead of iptables. Yes it worked, but the world moved on (and yes, I know, iptables is archaic at this point in time).

It's a shame that System V became so widespread instead of OpenRC.

Re:Good...?

[RabidReindeer]

One of the biggest selling points of Linux for me was that its log and config files were text files.

When I first started working with OS/2, one of my principal frustrations was that each and every IBM program product had its own proprietary config and log file format that could only be accessed using a product-specific utility. In Linux, the standard text utilities were all that were needed, and there are text utilities for almost every conceiveable way to search or update those files.

While there are certain things I like about systemctl and the newer Linux logging manager, their departure from this inherent simplicity disturbs me. It's aking to the trend to provide "improved" systems like Gnome3 or Windows 8 where your gains are offset by your losses.

Even a relatively open binary system like OLE/COM turned out to be more trouble than it was worth for me. I'd rather not throw out the good with the bad.

Re:Good...?

[Billly Gates]

The bad is is SysV not event driven.

This might be ok for servers but lets say you have a laptop with Ubuntu. You are on a network and it goes to sleep at work. You grab it and head to the airport for a trip and the laptop wakes up elsewhere. All of your SYSV scripts to do things like pass settings to daemons relating to network and Samba get messed up.

With an event driven system you tell it to do things based on conditions or events such as your laptop going to sleep and waking up on a different network as an example. You can use SystemD to re-initialize itself not just on startup but when things happen with this new ability. A hacking attempt on a server, an unplanned reboot, or anything else

The bad about SystemD compared to upstart and Apple's or Sun's event driven systems:
- no text files
- binary reporting
- quite complicated compared to other event driven systems like the older upstart

System admins hate systemD as it does not follow the Unix philosophy of text files and now awk, sed, grep, or perl to batch jobs :-(

Some also is resistance to change as many unix old timers hated anything new by Sun and did not want to relearn writing new scripts all over again. But, this tries to solve a problem like the laptop example but at the cost of complexity and non integration.

Re:Good...?

[DikSeaCup]

Have you ever tried logging into a box at runlevel 3 and typing "startx"?

On the super rare occasions where I'd need a GUI at the console of a system, this would work well enough for me (assuming all of the proper packages were installed).

A regular practice for me was to do installs as "minimal desktop" and then during the final configuration, change runlevel to 3 in inittab.

Re:Good...?

[nabsltd]

In System V you have to define network as a number and make sure everything that depends on it has a bigger number and everything it depends on to have a smaller number. systemd's dependency model is also smart enough to start processes in parallel.

If only systemd were really "smart enough", it would be great. Unfortunately, if you have a sevice that needs another service 100% functional before it can run, systemd has no way to describe that in the dependency files nor to test it.

All systemd uses to define a "running" service is that a process doesn't throw an immediate error upon startup. And, that's all it can ever have, unless the service is specially coded to be systemd-aware or does something like create a file in /var/run after it has fully initialized, and the dependency can be written using file existence. This really isn't any different in SysV, but at least there I could trivially edit the startup script of the dependent service and add some sort of test.

Because there is no way to test every combination of services, there is no way to reliably create systemd dependency files that will always work. Because of that, we get things like rc.local running before other services have started completely.

Re:Good...?

[amorsen]

Indeed, journalctl is probably what I dislike the most about the current systemd stack. For one thing it is slow with full text search in large log files -- it is reasonably fast if you use the built-in column-specific search, but just running fgrep on it is not really feasible. In contrast, fgrep is ridiculously fast on modern systems as long as your log files stay below a few gigabytes in size. Also, the output of journalctl changes (mostly for the better) when you use it with pipes, which can be quite surprising.

The other major problem with systemd is how difficult it is to debug boot failures. It is quite annoying when an fstab which was correct with upstart results in silent boot failure with systemd.

Re:Good...?

[F.Ultra]

Well good then that the ini files for SystemD is text and that you can export the textlogs from the logger.

Re: Good...?

[Anonymous Coward]

Don't doubt it. Google it.

Re:Good...?

[F.Ultra]

Yes, a two or three line ini file for SystemD is soo much harder than a 5k SysV script ;)

Re:Good...?

[s.petry]

You are correct, I confused upstart with systemd in my comment.

Re:Good...?

[Bacon Bits]

Yes, and you have to understand that that only works because your DE of choice has bent over backwards to make sure all it's dependencies are running and functional when you try to start it. That is to say, startx has to duplicate functionality of init because init is too stupid or too unreliable to be able to do it for your DE.

This issue can be generalized to any significantly complex application. That means you already have a half dozen "init systems" working on your systems. They're all independent (even though they maybe should know about each other), and you can't manage them universally (even though you might want to fire things off with system level events, like restarting a service if it crashes), and you certainly can't be sure you're not stepping on each others' toes.

Essentially: a large enough number of people noticed that the same features for starting and managing processes were getting implemented over, and over, and over. They realized that these functions belong in the init role -- because only init has the authority and knowledge required to not screw it up -- but that sysv-init didn't have the capability to do any of that.

All this began to happen perhaps 10 years ago, when other operating systems (e.g., Windows, which has had service dependencies and crash recovery since Windows 2000) showed what a more feature-complete init system was capable of.

At this point these "why do we even need a new init system?" questions are like someone watching I-40 getting repaved in the 1970s and asking "why do we even need Interstates?"

Re:Good...?

[dreamchaser]

CentOS 6 doesn't. I know Centos doesn't track RHEL 100%, but that's a significant difference...

Incorrect, or you're just making shit up.

This is relevant to the discussion. Operative section:

Starting with version 6, however, CentOS has turned to a new and better init system – Upstart. Upstart is faster than System V init because it starts services simultaneously rather than one by one in a certain order. Upstart is also more flexible and robust, because it is event-based.

So, you were saying?

Re:Good...?

[Anonymous Coward]

System admins hate systemD as it does not follow the Unix philosophy of text files and now awk, sed, grep, or perl to batch jobs :-(

That's a good reason to hate something. Need a simple configuration change? Well, start by opening the registry hive of the default user...

Re:Good...?

[Anonymous Coward]

startx has to duplicate functionality of init

No, that functionality is contained within xinit or the display manager (the latter of which is, in fact, spawned by init on most systems).

Re:Good...?

[Anonymous Coward]

This.

With processors only getting more powerful, there's no reason in the world to wander from easily-human-readable text files into the weeds of "structured" crap.

Re:Good...?

[Anonymous Coward]

Unfortunately, if you have a service that needs another service 100% functional before it can run, then you need to hunt down the fucker who wrote it and teach him about race conditions between dying of acid and overheating when dropped into boiling sulphuric acid.

Because there is nothing which is too strong to teach programmers that you can never rely on a resource being available immediately when you need it and you always have to be ready for your cooperating process to be restarted by the administrator.

Captcha; "employs" which should scare you because I am the PHB. Tomorrow I could be your PHB. Do not create another race condition.

Re:Good...?

[Anonymous Coward]

Sounds like we need to extend systemd with an Expect type system so it can run tests on a started process and trigger events based on the result, then.

Re:Good...?

[Bacon Bits]

That is a detail not particularly important to my point. If you wish, s/startx/xinit/.

Re:Good...?

[JesseMcDonald]

Unfortunately, if you have a sevice that needs another service 100% functional before it can run, systemd has no way to describe that in the dependency files nor to test it. All systemd uses to define a "running" service is that a process doesn't throw an immediate error upon startup. And, that's all it can ever have, unless the service is specially coded to be systemd-aware or does something like create a file in /var/run after it has fully initialized, and the dependency can be written using file existence.

That isn't true. Putting aside the systemd-specific sd_notify() API for reporting just how completely the service has been initialized, and the socket activation model which allows other services to connect while startup is still in progress, systemd also supports traditional "forking" daemons which complete their initialization before the main process exits. You can also use the ExecStartPre and ExecStartPost fields to inject arbitrary commands into the startup process separate from the daemon itself.

The best case short of actual systemd integration is that the service already does the right thing with the fork-and-exit model, so that it's ready to be used before any other services are started which depend on it. But even if that isn't the case there are ways to deal with it under systemd, up to and including custom shell scripts for the really complex cases.

Re:Good...?

[JesseMcDonald]

The bad about SystemD compared to upstart and Apple's or Sun's event driven systems: ... - no text files

What do you mean by that? The database used by journald may be binary (with the ability to export to text), but systemd unit files are simple text files with an INI-style layout. There are some other systemd configuration files with different formats for historical reasons, but to my knowledge all of them are still text.

Re:Good...?

[Eunuchswear]

Twat. Mod -100 wrong

Re:Good...?

[Eunuchswear]

I understand that better reporting tools are a good thing (can you explain more to those of us who haven't migrated?). But otherwise, it's an init system. Just how often are you rebooting that server?

Well, that is the problem.

In real. modern, systems (servers, desktops, phones), there is no longer the binary distinction "booted/not booted".

Hardware gets hotplugged. Connections (and so network file systems) become available or are disconnected.

"init" doesn't just do its work at boot, but all the time.

Re:Good...?

[Eunuchswear]

As a sysadmin, the complexity in creating a random startup script for a new custom service on a systemd server is a huge barrier to entry.

So make a sysv init script.

Backwards compatibility, heard of it?

Re:Good...?

[RabidReindeer]

Well good then that the ini files for SystemD is text and that you can export the textlogs from the logger.

Exporting isn't the same as processing in place. And the other day, in fact, I ran into an issue where messages that I expect to be able to "tail" out of the older log simply couldn't be found.

The systemd authors have already admitted that there are certain functions that the older script-based ini's could provide that their strictly-declarative system at present cannot. Having text formatted files is useful but not being excessively restricted in what the text can do is also important.

Re:Good...?

[Omicron32]

> System admins hate systemD as it does not follow the Unix philosophy of text files and now awk, sed, grep, or perl to batch jobs :-( Firstly, it's systemd. I'm not sure where you're getting the capital from. Secondly, generalise much? I'm a long-time Linux system admin and I can't wait until systemd filters down to server distros like CentOS and Ubuntu LTS. It will make my job a whole lot easier.

Re:Good...?

[Anonymous Coward]

My problem is with how long it took to fix the issue with journald ignoring the SystemMaxUse setting in /etc/systemd/journald.conf. Systemd people need to respond to bug reports in a more timely fashion.

Re:Good...?

[Anonymous Coward]

So what.

Re:Good...?

[Zero__Kelvin]

"Exporting isn't the same as processing in place."

It is on Unix/Linux

Re:Good...?

[Zero__Kelvin]

My systemd based system has run levels. Doesn't yours?

"System V has a scrict sense of a run level. For example, if you want a full desktop, run level 5 is often used, for a headless server, run level 3. What if you have a box that is headless most of the time, but you want to be able to run a full desktop sometimes? With System V you would change from run level 3 to run level 5 which would, depending on implimentation, stop and start services that are needed by both. Systemd instead has the concept of targets"

Hard Stop. That is where you went wrong. You apparently don't understand that targets don't replace run levels. Targets make run levels smarter.

Re:Good...?

[Anonymous Coward]

What a mess. Systemd appears to have all sorts of hacks and a very inconsistent model to deal with what in reality is only one thing; dynamic dependency management. A pity systemd wasn't properly designed to separate all the dynamic dependency types from the static dependences and all the other cruft they've special cased. Even logs are just another dependency. Unfortunately this is the programming fashion at the moment, fulfilling feature lists in a messy way rather than spending even 5 minutes thinking about the fundamentals to make the system far smaller and more maintainable.

Re:Good...?

[Anonymous Coward]

Even logs are just another dependency.

LOLWUT. I guess you mean "sysv can do it too it's just dependent on me editing all my initscripts and adding 2>&1 > /var/log/init.log to the end of each line". I guess you can also say sysv can restart apache if it crashes too, it's just dependent on you writing a script to do it. Managing dependencies? Sounds less sysv and more sysadmin. Other people are complaining "but all my heavily customized startup scripts will break!!1!one" at least when they complain, they acknowledge who's actually responsible for them.

As for the inconsistency, this is only until services and applications become systemd aware and use it. Until then the services that worked like they worked in sysv (fork and exit) will fork and exit just like they used to and will continue to do so without any of the magic features.

There might be issues with bloat, but if you have them you can just install sysv yourself and write your own scripts to start everything.

Re:Good...?

[F.Ultra]

tail of a file is nothing more than exporting the content of that file, it doesn't matter if the file was in binary or text, that you could tail or cat from it is what is important and that has not changed. If your older log couldn't been found then that is a problem with log rotation and has nothing to do with wither the log was binary or text in it's storage format.

Re:Good...?

[fnj]

RH6 went to systemd?

Yes.

I don't see systemd on any of my RHEL6 or CentOS6 machines.

Nor do I, but I see it on my RHEL7 beta, and we will all certainly see it in RHEL7, since this has been officially stated.

My only concern is how deeply it ties into the Linux Kernel, which means that we're losing the freedom to use other Unix operating systems once we tie to systemd.

Funny, I'm not losing any freedom. I have actually increased my exploration of BSD. It continues to work using init scripts, just like it did before anyone dreamed up systemd. GNOME3 may require systemd (I don't think the requirement is absolute; you just lose certain functionality without it), but there is zero chance I would ever touch GNOME3 anyway.

Re:Good...?

[Eravnrekaree]

Text files are not better for everything, especially where you want the best performance with being able to quickly access a record in a large file, an indexed format can be much faster. The Unix passwd database for instance has long been text. If you had thousands of users, your looking at slower performance to parse the file than if there were a b-tree index to find the records. I think admins should have a choice between text and binary formats in situations like these. If you have a standardised binary format, or one that uses a library that is widely used by a lot of programs, such as SQLite, you should be able to have a potentially large number of choices in clients to access the file since the file format is widely used, any reader of the format would work with files used for configuration of many different programs. SQLite has begun to fulfill this need. In many ways such a widely used binary format would make things potentially better than a text file, not only being ablwe to be accessed by a wide array of client programs, the files can also be easily programmatically accessed through an API. In fact, text files are far from standardized so if you needed to programmatically access values in say, apache.conf, its going to be rather complicated to do as you need a parser for that format in the file. So in many ways the idea text files are better is questionable, as you can have many advantages with a widely used binary format.

Re:Good...?

[Ash Vince]

I think it's good Shuttleworth was able to suck up his pride and go along with this decision to prevent fragmentation. I do however call the original decision slightly into question, but that's only because I've gotten sort of used to upstart. Hopefully anything good that was implemented in upstart but was not in systemd will make its way over.

I doubt he gives two shits about pride, he did not develop upstart personally (so has less reason to feel attached to one of his creations) and now does not have to pay the developers to work on upstart in house. You can be pretty sure the only reason Cannonical created upstart was because there was something they needed but could not be done using sysvinit, now that ubuntu's upstream moved to something they can use he is probably over the moon.

Re:Good...?

[Wdomburg]

Processors aren't the bottleneck; I/O bandwidth is. The "weeds of 'structured' crap" is the difference between a log query running in milliseconds or hours when you're generating terabytes of log data every day.

Re:Good...?

[Anonymous Coward]

I don't like systemd AT ALL, but you have just pointed to a reason for me to like it even less. When admins or users with a clue talk about tailing a log, they're thinking about following a log in real time.

Saying

tailf /var/log/apache/access.log

lets you see the log of the web requests scroll by. Pretty often enough I want to tail some log or another to see if some event is happening and to get a quick idea of whether it is happening right. One of the logs I would tail is /var/log/messages. That's one that goes away with systemd. I don't know how in the world you would be able to tail a log with systemd.

Re:Good...?

[Anonymous Coward]

The bad about SystemD compared to upstart and Apple's or Sun's event driven systems:
- no text files
- binary reporting
- quite complicated compared to other event driven systems like the older upstart

Systemd is not event driven. The systemd authors saw upstart's event driven architecture as a flawed design to an init system. It defines dependencies rather than events.

Re: Good...?

[buchanmilne]

1) You can use a different logger with systemd
2)To watch log messages with journal, journalctl -f

There are still some things I don't like about the journal (I haven't seen how to specify different retention rules for logs of different applications), but then I've only spent a few minutes actively using it.

Maybe the thing that irritates me about journal is I don't know what previously unsolved problem it is trying to solve, while making some log processing difficult.

Re:Good...?

[Anonymous Coward]

Because you can. For now.

Re:Good...?

[Anonymous Coward]

Begin the author of an open source daemon that does everything about daemonization as perfectly as I can manage, my beefs are these:

1) systemd doesn't even *try* to be portable. While my primary target may be the majority of users on Linux/x86_64, I want my open source daemon to work on Debian/kFreeBSD, FreeBSD, NetBSD, OpenBSD, and OS/X, at a bare minimum. If it works in more places, the more the better. My daemon should at least be damn-close to fully operational on a POSIX-y platform I've never heard of. systemd provides a completely, very alternative way of doing all the standard daemon things (daemonization itself, process management, logging, sockets, etc), but provides zero portability beyond Linux. The very least they could do is wrap today's systemd in a library with a standard API that does the right thing on non-systemd platforms. Otherwise I end up writing all of the painstaking traditional portable code *and* separate systemd code, just because systemd exists. As I was already doing everything correctly under the portable model, and systemd actually fucks things up for normal programs (the most egregious of which is stderr+logging, but others abound), I now have to go out of my way to accommodate systemd separately.

2) Even assuming a Linux-only world, systemd basically replaces a plethora of traditional POSIX-y APIs at various layers with a whole new one that does basically the same things, slightly simpler. However, it lacks the power and flexibility of the underlying traditional APIs, which leads to...

3) My really big beef: my daemon has a "fast-restart" mode. You tell it to restart, and what actually happens is a new daemon is launched, does all the expensive and time-consuming operations of startup separately, and then signals the old instance of the daemon to release sockets to it (or in some cases, takes over the sockets with zero downtime using SO_REUSEPORT). It's a huge win for the user - they can reconfigure everything and do a service restart which needs to spend 10's or 100's of seconds re-loading/parsing/munging runtime data and lose zero (or worst case, a few ms worth of) actual user traffic. However, while this fast-restart mode works perfectly fine under a normal POSIX model, it's completely broken on a systemd-based system. I'm still investigating this one, as I may be able to make it possible to compile the daemon with e.g. --use-systemd and have it do some nasty cgroups tricks and make it work anyways, but I shouldn't fucking have to :P It worked before, and your ugly new thing should allow it to continue to work as before.

Re:Good...?

[DarkOx]

Systemd is about fragmentation. Is to be requires all the services to be modified to work properly with it because it has to see their exit status because it doesn't exec itself. What this will do is effectively kill the non Linux ecosystem for any software that doesn't ship the core OS. It'll effectively make like software incompatible with the non-Linux world.

Systemd represents a major step backwards and compatibility and is going to undermine the entire open-source effort.

Re: Good...?

[Anonymous Coward]

Rh6 uses upstart (a fairly old version) Not systemd

Re:Good...?

[Anonymous Coward]

Unfortunately, if you have a sevice that needs another service 100% functional before it can run, systemd has no way to describe that in the dependency files nor to test it.

All systemd uses to define a "running" service is that a process doesn't throw an immediate error upon startup. And, that's all it can ever have, unless the service is specially coded to be systemd-aware or does something like create a file in /var/run after it has fully initialized, and the dependency can be written using file existence.

That isn't true. Putting aside the systemd-specific sd_notify() API for reporting just how completely the service has been initialized, and the socket activation model which allows other services to connect while startup is still in progress, systemd also supports traditional "forking" daemons which complete their initialization before the main process exits. You can also use the ExecStartPre and ExecStartPost fields to inject arbitrary commands into the startup process separate from the daemon itself.

The best case short of actual systemd integration is that the service already does the right thing with the fork-and-exit model, so that it's ready to be used before any other services are started which depend on it. But even if that isn't the case there are ways to deal with it under systemd, up to and including custom shell scripts for the really complex cases.

So, grandparent was right.

Re:Good...?

[Blaskowicz]

The overlord daemon is an advantage, previously we all used monitoring scripts to do things for us. The system now has it built in.

The disadvantage to the overlord daemon is when I do a google search to know wtf it is, I get answers about actual evil overlords like Satan itself or an undead evil creature.
So I don't understand much what this is about and I fear that systemd is an evil overlord with huge dependencies (like a fifty meter high gritty castle) and integration with malefic gnomes.

Re:Good...?

[Rich0]

Well, it sounds like #3 might require an additional option in systemd if it doesn't already exist. The problem is that systemd has no way to know that your previous incarnation of the daemon refused to die because it knows what it is doing, vs it refusing to die because it is broken. There really isn't a workaround other than telling systemd not to kill off the old one. Your daemon is tagged with cgroups and I imagine that is hard to escape (maybe if it is root it can hack its way out).

So, the behavior you're struggling with is a feature. What your daemon does is a good thing, but few daemons work this way and so it probably hasn't gotten attention yet. All systemd should have to do is not kill off your old process before starting the new one - it could potentially stick each in a separate cgroup to help manage this.

Re:Good...?

[Rich0]

This really isn't any different in SysV, but at least there I could trivially edit the startup script of the dependent service and add some sort of test.

You should be able to call a script from a systemd unit to run your test.

Also, systemd is able to manage dependencies for sockets/etc. So, in many cases if the units are properly implemented you can avoid starting a new program before the old is ready, or more often start them in parallel but have the second program block when it tries to do something before the dependency is ready. I suspect many daemons haven't had this implemented yet, since for the most part systemd is new and most of its users are just working to get it working at all.

Re:Good...?

[Rich0]

++

systemd units are trivial to write.

It could use some better documentation around the various targets and recommended best practices. There are a million ways you can get a daemon to run, but you really need to do it the right way if you want it to handle all the edge cases (like a file it needs is NFS-mounted, and thus it has a net dependency that might not otherwise be apparent, and so on).

Re:Good...?

[psychoticmeow]

The systemd way of handling problem 3 is to create a unit.socket configuration file - on restart it will stop the old service, capture the sockets, start the new service and hand over the sockets to it. http://www.freedesktop.org/sof... I hope this helps, although I don't know how extensive the functionality is having never used it myself.

Re:Good...?

[JesseMcDonald]

That doesn't really solve problem #3, because while clients can still connect they won't actually be serviced until the daemon finishes restarting, with up to several minutes of downtime. However, I think you could use the ExecReload option to implement the "fast-restart" mode. It would need to send a signal to the main process, causing it to fork and exec a new instance of itself. When the new instance is ready to take over it would then signal its parent process to exit. This appears to work provided that you set Type=forking and GuessMainPID=no in the [Service] section, otherwise systemd will stop the child process automatically when the main process exits.

Re:Good...?

[Anonymous Coward]

Well, it sounds like #3 might require an additional option in systemd if it doesn't already exist.

It's a mountain of kludges on top of kludges. At some point they'll have to say "do over". And what would that mean but "screw over".

Captcha: struggle

Re:Good...?

[Anonymous Coward]

I really edit so rarely any common config files so take this as is.

I Do LOVE the idea and functionality that every setting is available as pure text file and I dislike very much the systemd because what I know it using binary logs etc.

I have only few personal experiences with systemd (I have used Arch Linux for now 3-4 years) and I don't like it.

Like example this computer what I now use to write this, has been on shelf for 6 months because I couldn't resolve why I can not get WiFi networking working at all even when I have installed NetworkManager and disabled netctl. At that time I went trough the guide of NetworkManager in Arch Linux wiki without answer.

Until week ago my SSD died (not even close to write cycles!) when Windows on HDD got a blue screen (this was fourth time Windows BSOD has destroyed separated drive where Linux system is located and they don't have anything to do each other than Linux drive is connected to same motherboard, all these in four DIFFERENT computers in last 5 years) and SSD didn't anymore recognize at all. This forced me to re-install Arch Linux from scratch what I had maintained all the years on that computer without re-install (so successful proof for me how well rolling-release works!).

So I managed to install Arch again to SSD and hit hard to same problem of networking. After searching web I found two discussions about similar problem people had. And all was because systemd.

The Arch Wiki doesn't explain directly that you need to go and disable dhcpcd.service AND remove all automatically generated network profiles from system.d config directory.
Yes, there is saying "Disable all conflicting network services" but so far DHCPCD has not been conflict with NetworkManager. I had disabled all conflicting network services and not even thinking dhcpcd would be such one. (My bad yes).

And once I learned that and the fact you need to delete the config files, I got working WiFi and wired again! Way to GO!

So here I am happy with resolved problem what Arch Linux wiki didn't want to directly explain (There was mention added to wiki but some asshole Arch wiki maintainer reserved because the mention of "conflicting services" is enough instead explaining that profile files AND DHCPCD needs to be disabled (the wiki directly say you need to have dhcpcd.service enabled though!)).

But I couldn't troubleshoot the networking at all like I could have with config files. Even when going trough the systemd own tools what even the wiki stated.

I can only say, yes systemd has nice performance but WHO THE FUCKING IDIOT DESIGNED IT?! (AFAIK it is the same person who came up with PulseAudio!)

All configuration and syntax are crazy! Like SysV kind level switching was so easy with "init 3" and "init 5". But NO! You couldn't implement same simple sane logic to systemd but you need to use "systemctl isolate XXXXX.service" and figure first out what levels there are (graphical.service isn't same as "runlevel5.service").
How about then just have "systemctl level5"? Have levels 1-6 by default and then allow enable all fancy "graphical" "networking" etc.

Re: Good...?

[F.Ultra]

AFAIK the problem that journal tries to solve is logging of meta data, i.e beeing able to log variables in a well defined manner and not only plain messages

Re:Good...?

[X0563511]

What the hell? How have I not ever noticed this?

I guess that's a point in Upstart's favor, if I've never noticed the change...

I agree

[Anonymous Coward]

Good call. Ubuntu needs to keep the same basic internals as upstream otherwise what's the point.

Re:I agree

[hcs_$reboot]

systemd is as good as init daemons management system - the problem is how the transition is going to be performed? Hopefully it won't be like the gnome-classic => Unity mess. Init and systemd will both have to be available, giving time to administrators to migrate what could not be automatically transferred and specific applications.

Re:I agree

[ZarathustraDK]

Your comment made me switch back to Ubuntu. Seems like all the tinfoil-whiners are gone from there now.

Re:I agree

[caseih]

Fedora made the transition some time ago, and from a user's point of view it was completely transparent.

RHEL7 beta has transitioned to systemd, and again it's pretty transparent. The old service command is still there and thunks through to systemd. The only time you really notice the difference is if you want to install a custom daemon. You can either use an init script, or you can create a simple systemd service file. There are a few systemctl commands to learn. But really, it's as close to a painless transition as you can get.

Re:I agree

[nabsltd]

Fedora made the transition some time ago, and from a user's point of view it was completely transparent.

When you edit a file in /etc/rc.d/init.d and your changes don't have any effect because that service is actually controlled by systemd, I wouldn't call that "completely transparent".

Re:I agree

[Anonymous Coward]

I left from Ubuntu to Debian, thanks to Unity. But as Debian and Ubuntu is moving to systemd, where else one can go? Back to FreeBSD or DragonflyBSD?

Re:I agree

[Eunuchswear]

systemd is as good as init daemons management system - the problem is how the transition is going to be performed? Hopefully it won't be like the gnome-classic => Unity mess. Init and systemd will both have to be available, giving time to administrators to migrate what could not be automatically transferred and specific applications.

Well. since the Ubuntu plan seems to be "copy Debian" you don't have to worry. It will be done right,

Re:I agree

[Zontar The Mindless]

Shame on the fanboi who modded you off-topic.

The politics at Debian do not interest me much, but I did spend a few hours using Ubuntu several years ago, could honestly not see what all the excitement was about (in fact, I found it clumsy and generally painful to use). Went right back to openSUSE, where I remain today. (CentOS for servers.)

Re:I agree

[shutdown -p now]

Gentoo is on OpenRC, which is basically SysV init on steroids (named runlevels, optional declarative service description files, cgroups etc).

If that falls, then yes, FreeBSD would be the next stop.

Re:I agree

[Anonymous Coward]

Cool! Tell us more about what distros you use, Slashdot poster "MightyMartian". We're all super-excited to hear.

Re:I agree

[Rich0]

If you wanted to go slow, I always thought that a simple transition strategy would be:

1. Create a shell script that reads in a systemd unit and implements the start/stop behaviors for the legacy service manager.
2. Slowly replace all your existing service manager scripts with the new one and systemd units, still running under the legacy service manager.
3. Once all your scripts are replaced, begin testing systemd in earnest.
4. Make the switch in service manager.

The idea is that you only have to maintain one service manager config per service at any time, and you can update them as you go. You're basically adding the fairly simple elements of the systemd service manager to your legacy sysvinit as a compatibility layer. You wouldn't need to build all the fancy stuff (namespaces for daemons and all that) - just the stuff that you already do with your legacy service manager.

Re:I agree

[GPLHost-Thomas]

Stay with Debian, and install OpenRC on it. I will do what I can so that it will be ready for Jessie. Tests and feedback welcome. FYI, it already works on both kFreeBSD and Hurd, so it cover all Linux and non-Linux ports of Debian.

Xubuntu 13.04 Live CD is already running systemd

[Kremmy]

Maybe the linux distributions should stop pulling an AppleSoft and start maintaining their shit instead of rewriting it again.

What?

[Anonymous Coward]

They aren't implementing their own?!?

Well color me surprised!

[iwbcman]

omg! could this be my first, first post! Karma! yeah!


Good call Mark, glad to see Ubuntu embrace what is comming. Now, for the interesting part, it is time for sys admins to rally and push for the interfaces/workflows that we need. systemd obviously has certain strengths, now lets bring the experience and know how of good sys admins to make working with systemd mutually beneficial for all.

Re:Well color me surprised!

[wiredlogic]

omg! could this be my first, first post! Karma! yeah!

Nice try. You still have to wait a few months before everybody else leaves for good. Then you can have FP to your heart's content.

Re:Well color me surprised!

[iwbcman]

oh well i was within the first 100 posts!....

the one time i am fooled into claiming it! and not even received with the humour intended! pffff!

Re:Well color me surprised!

[Zontar The Mindless]

Apparently the Grey Men have mod points today. What a pity.

Whats wrong with init?

[Viol8]

People talk about parallel start up , well you can do that with init anyway. Its it smarter with dependencies or is it just change for the sake of it? I'm really not thrilled with the prospect of yet another config language, there are quite enough already.

Re:Whats wrong with init?

[Anonymous Coward]

"I know nothing about this software but I'm gonna bitch, complain and sling shit at it anyway. How dare they move my cheese!"

- Typical Slashtard

Re:Whats wrong with init?

[Anonymous Coward]

Parallel start is something already doable in Debian stable, you have to enable some flags in rcS script and install an script that parse the LSB headers in the rc init scripts, and organize them in in deps. Everything combined enables a parallel startup.

But the point here is not 'just' parallel startup. For what I've seen, the systemD init has some technical advantages when troubleshooting, logging and doing some other stuff. It's the combo that helps and there were some nice technical discussions here https://wiki.debian.org/Debate/initsystem/systemd

Re:Whats wrong with init?

[EmperorArthur]

Lets face it, sysV init is complicated. Well, the theory behind the old linear start from init script 00 and move to init script 99 isn't, but the modern implementations and the scripts themselves are complicated. I mean you're doing dependency checking and a whole bunch of other things in bash scripts. Compare that to a systemd service file, which is overall nice and readable. So, part of it is factoring out the logic from the variables. The other big thing is bash and the tools used by init scripts are like using a sledgehammer to tap in a finishing nail.

I'm not going to say that systemd is perfect. I like the "unix" way which is to use small units that do one thing well instead of anything. That's part of the reason I see bash init scripts as too much for the job. Unfortunately, the systemd authors look like they want to throw in everything but the kitchen sink. Well, everything that they can't just port to kernel space that is. But that's the thing, Linux is a Monolithic kernel. Like it or not, the "Linux" way is to have one uber optimized thing with modules to handle everything.

In the end, I just really like the ease of use of service files. Oh, and the stupidly fast boot time on my laptop is really nice. People who say boot times don't matter aren't living in the real world.

Re:Whats wrong with init?

[causality]

"I know nothing about this software but I'm gonna bitch, complain and sling shit at it anyway. How dare they move my cheese!"

- Typical Slashtard

Knowledge of the new software is a separate (easier to cheaply ridicule, stay classy) question. The issue with systemd: it reeks of a solution looking for a problem.

If the existing init systems were causing widespread grief I'd be much more receptive to it. So would just about anyone currently questioning systemd's rapid adoption. Right now the reason for installing it is "everyone else is adopting it as the new standard and it will be increasingly difficult to go against that standard." That's not the best of selling points. It's not like "wow all these problems and limitations I had been experiencing will finally go away!" like you get with truly sensible and evolutionary changes.

If you think that shouldn't matter to anyone, you could explain why you think so. In the meantime, please make an effort to understand the viewpoint of those who disagree with you. Then you stand a real chance of actually addressing the issue, or at least of not embarassing yourself with smug hand-waving and knee-jerk dismissals based on your annoyance that everyone doesn't already agree with you.

Re:Whats wrong with init?

[Anonymous Coward]

I heard a few things like:
- safety (proper locking between dependencies and concurrent runs of the same command)
- flexibility (how precisely you can define your dependencies and events)
- speed of booting

Re:Whats wrong with init?

[Anonymous Coward]

Knowledge of the new software is a separate (easier to cheaply ridicule, stay classy) question. The issue with systemd: it reeks of a solution looking for a problem.

Based on having used it or because your cheese got moved? All these distros wouldn't be adopting it if what you say is true, especially Debian. Get back to me when you have a real argument not cliches.

Re:Whats wrong with init?

[Anonymous Coward]

Start-stop-daemon makes for reasonably clean init scripts. It takes care of the details of managing the service so you only have to write a simple case statement in the script.

Re:Whats wrong with init?

[gweihir]

The only thing wrong with init is that a cretin named Poettering did not create it. As this person wants to set himself a statue, this is apparently reason enough. There are tons of things wrong with systemd though, not the least of it that it completely ignores UNIX philosophy and violates KISS.

Incidentally, systemd is unstable, hard to debug, hard to configure, complex, thinks binary log formats are acceptable and the same cretin brought us pulseaudio.

Re:Whats wrong with init?

[causality]

Knowledge of the new software is a separate (easier to cheaply ridicule, stay classy) question. The issue with systemd: it reeks of a solution looking for a problem.

Based on having used it or because your cheese got moved? All these distros wouldn't be adopting it if what you say is true, especially Debian. Get back to me when you have a real argument not cliches.

So you prefer to repeat yourself rather than address the real root cause of the remaining resistance to systemd? You definitely missed an opportunity there.

I said I question systemd's adoption. I didn't say I was against it, nor did I say that other people shouldn't use it. Even that offends you, and you resort to a form of "everyone else is doing it!" (the antithesis of thinking) to justify yourself. This is why you are smug.

I reasonably put a valid question to you and you weren't prepared for that at all. That's a shame, because if systemd is truly so wonderful, its adoption could only be harmed by advocates like you.

Re:Whats wrong with init?

[fishybell]

Yes, you can do parallel startup with System V. You also can make a systemd init process that doesn't do anything in parallel.

Yes, systemd is smarter with dependencies in the sense that it has dependencies and not a numered list. Yes, you can have a System V script that manages it's own dependencies, but because you can do an infinite number of things with System V scripts many people have tried. I've ran across dozens of System V scripts that are hundreds of lines long even without couting the standard ". /etc/init.d/functions" size, which, on my system, is almost 600 lines long. Systemd simplies this by having a much larger library of functions and uses the presumption that you'll never call a script without using systemd to manage it. No longer does every script have to define a start, stop, restart, condrestart, status function; it's handled by systemd. No longer do you have to do checks for your PID file; it's handled by systemd. No longer do you have to make sure your script will always run after another script even if that script's chkconfig number changed; it's handled by systemd.

In the end, yes, it's another config language you'll have to learn, but it's worth it.

Re:Whats wrong with init?

[tlhIngan]

Lets face it, sysV init is complicated. Well, the theory behind the old linear start from init script 00 and move to init script 99 isn't, but the modern implementations and the scripts themselves are complicated. I mean you're doing dependency checking and a whole bunch of other things in bash scripts. Compare that to a systemd service file, which is overall nice and readable. So, part of it is factoring out the logic from the variables. The other big thing is bash and the tools used by init scripts are like using a sledgehammer to tap in a finishing nail.

I'm not going to say that systemd is perfect. I like the "unix" way which is to use small units that do one thing well instead of anything. That's part of the reason I see bash init scripts as too much for the job. Unfortunately, the systemd authors look like they want to throw in everything but the kitchen sink. Well, everything that they can't just port to kernel space that is. But that's the thing, Linux is a Monolithic kernel. Like it or not, the "Linux" way is to have one uber optimized thing with modules to handle everything.

Well, the BIG problem is maintenance. SysV scripts have both a S and K variant on when to run when switching levels, and you can bet very few people have it properly set up if you do switch levels. Enough so that switching levels is fraught with danger - you can probably start at level 1 (single user), and switch to 3, 4, or 5. Maybe you can get back to 1 because the extra demons get killed. Maybe.

In the end, it's bit of a maintenance hassle, and while completely understandable, it's a nightmare.

In fact, I'm guessing most utilities don't even bother handling the case - you just reboot and forget about it.

After all, computers are good at doing stuff automatically - so stuff like maintaining which services should run at which runlevels should be automated - the init can figure out what it needs to start, what it needs to kill and the order based on dependencies. All the user needs to do is select what needs to run at what runlevel, and the tool does the rest.

Then there are the various hacks to SysV - PID files (if so many tools need to know the daemon PID, why not have init actually do that work than requiring every script to do it manually?), the fact that state tracking isn't really in the system, and if you need services to relaunch on failure within limits, there ought to be a way to do it without requiring a trip to /etc/inittab to specify that fact.

Re:Whats wrong with init?

[Anonymous Coward]

So you prefer to repeat yourself rather than address the real root cause of the remaining resistance to systemd? You definitely missed an opportunity there.

You didn't answer the question. So, yes, I will repeat it until you give an actual answer not one of the many cliches from the "I simply hate Lennart" crowd.

I said I question systemd's adoption. I didn't say I was against it, nor did I say that other people shouldn't use it. Even that offends you, and you resort to a form of "everyone else is doing it!" (the antithesis of thinking) to justify yourself. This is why you are smug.

Offended by what? Some ignoramus parroting tired cliches? Don't make me laugh.

Re:Whats wrong with init?

[causality]

Well, the BIG problem is maintenance. SysV scripts have both a S and K variant on when to run when switching levels, and you can bet very few people have it properly set up if you do switch levels. Enough so that switching levels is fraught with danger - you can probably start at level 1 (single user), and switch to 3, 4, or 5. Maybe you can get back to 1 because the extra demons get killed. Maybe.

I know what you mean. I've used Linux systems that were set up that way, and it's messy and a bit of a nuisance to make sure the system is really going to do what I think it's going to do.

Personally I'm a long-time Gentoo user and my system runs OpenRC. Have you ever used it? It eliminates the sources of confusion you illustrate there. It's neat and it's simple and it works and I can forget that it's there. That's what I like about it. There's nothing I want it to do that it doesn't already implement.

Right now Gentoo is one of the few distros that supports a non-systemd installation, mainly because the idea that as little as possible should ever be forced on the user is one of their core principles. Gentoo has very few mandated default anythings and they encourage users to file a bug if they discover an unnecessary one. I am interested in systemd and I acknowledge it probably isn't taking off so well for no reason, but this is why I'm not in any hurry to adopt it.

BTW OpenRC does have a form of state tracking. It simply uses start-stop-daemon for this, so that each initscript doesn't need to worry about it.

Re:Whats wrong with init?

[Narcocide]

Look, you coward, systemd is written by someone who can't grock grep. I thought Debian could do no wrong too, but apparently no organization is impervious to beligerant ignorance.

http://ewontfix.com/14/ (posted elsewhere in this discussion by someone else, this is the well-organized counter-argument you claim to be willing to hear. read it then fuck off)

Re:Whats wrong with init?

[Billly Gates]

What is wrong is it is not event driven.

It is nice for example is you can set your laptop up for different networks and when conditions change such as it sleeps and wakes up on a different network it can respond differently. You do not have to write a complex script for every possible combination you can think of.

Just put in the parameters and tell it what to do with events.

It can be used too after booting up for servers so if a hacking attempt is detected it can dynamically change its firewall settings as an example and send an email to you. You could try to do this with conventional scripts but it would be a lot more difficult

I am not experienced enough to qualify whether systemD is a good implementation as upstart also is event driven and somewhat sysV init compatible. But this is why Sun and Apple are phasing out init with event driven systems like this.

Re:Whats wrong with init?

[Anonymous Coward]

Sigh. And oh, I'm a different AC.

What evidence do you have that the systemd author "can't grok grep"?

The problem with old-school SysV Init is that it makes the complicated code one needs to manage daemons someone else's problem. With systemd, I can replace three fairly complex shell scripts and a fairly large daemonizing C program with three simple systemd configuration files.

The security concern is FUD, plain and simple. If you can say "systemd has this many CVE reports", you may have a case. But, until then, people that paranoid about security should go back to their OpenBSD boxes.

Re:Whats wrong with init?

[F.Ultra]

And if I'm not mistaken your script can be set to start when /var/run/mysql.socket becomes ready instead of being started directly after /etc/init.d/mysql started and the mysql process decides to do a major table check so that the server is not accessible for 5 minutes which makes your daemon exit with an error since the database was not available at start.

Re:Whats wrong with init?

[nabsltd]

In the end, yes, it's another config language you'll have to learn, but it's worth it.

Why is it worth it?

I've heard lots of "systemd is better" claims, but not one real-world example of how it took 27 hours to debug a startup issue when using SysV, but only 13 seconds using systemd. And, I really don't care about boot times, because my physical servers take 10 times as long running through BIOS checks as they do going from grub load to system ready. Even VMs don't matter much, as they don't get rebooted very often, so saving 5 seconds on a 30-second boot time isn't really a big deal.

On the other hand, I've heard lots of stories from people who have to install a custom service (i.e., not from a "apt-get" or "yum install") on a systemd system and complain about how it took hours to get the dependencies right.

Re:Whats wrong with init?

[amorsen]

The config language, if you mean the syntax of what used to be the service files, is actually nice. Most keywords are well chosen and you can do partial or complete overrides of them by adding a file in the appropriate place in /etc.

The dependency system is good too, and being able to launch daemons without the traditional double fork is brilliant. The only surprise I have hit so far is that network.target does not actually wait till the network is up -- network-online.target does that.

If only those were the only changes...

Re:Whats wrong with init?

[inhuman_4]

The issue with systemd: it reeks of a solution looking for a problem.

The issue I belive is that the Linux kernel has been expanding its capabilities and the init system has not kept pace. Part of that reason is that to take advantage of Linux specific issues means breaking compatibility with other *nix systems.

Take cgroups for example. It is a Linux specific feature, and a great one at that. It can limit CPU, memory, and I/O processes not just just for one process, but for all of the processes that fork off of it. Along the way it solves the "escape by double forking" issue. For systems doing virtualization or running multiple servers it is exactly the kind of thing an admin would want for his services.

Or how about service dependancies? The sysem of A depends on B,F,K works great for all of our package managing systems, and has been for years. The is the reason upstart was adopted, the runlevel system is a very inelegant solution.

I'm not saying systemd is perfect. I really like status messages, but using a binary log file I think is a mistake. But it does provide new features that a lot of developers and admins will be able to take advantage of.

Re:Whats wrong with init?

[Eunuchswear]

You are a twat.

Three of my current phones use pulsaudio as a sound system (all of my computers do).

One of my current phones uses systemd. (The others use upstart I think). About half of my computers (~10) use sysvinit, the rest use systemd.

All of the pulseaudio/systemd systems work way better that the crappy mess that linux sound/linux boot management used to be.

Re:Whats wrong with init?

[HiThere]

Thank you for finally providing an answer that made sense.

Outside it that, I fully understand that attitude of people who don't like change for the sake of change...I'm one of them. Having to learn a new configure language is a pain when I'd rather be doing something else. But if there's a valid reason, that makes things more acceptable.

Re:Whats wrong with init?

[Zero__Kelvin]

"If the existing init systems were causing widespread grief I'd be much more receptive to it."

In other words: "I should be much more receptive of it."

Re:Whats wrong with init?

[Rich0]

Yup. I suspect Gentoo will be one of the last distros to make systemd a default, and I think that is because openrc really is the best traditional sysvinit implementation out there. I've used systemd on some of my Gentoo VMs and when you get into edge cases it can be clunky (I couldn't get it to wait until after getting an IP to try to mount NFS, for example).

The fundamental design is very good, but it will be a while before it completely surpasses openrc. It isn't unlike ext4 vs btrfs - the latter is almost certainly the future, but the former is very much the present.

Re:Whats wrong with init?

[thegarbz]

And, I really don't care about boot times, because my physical servers ...

Yeah sorry you're not really the target audience anymore. Year of linux on desktop and all that.

The reality is that just because you don't care because you run Linux on a server doesn't mean that boot times are something important that Linux distros really need to work on.

My Linux server is headless, does that mean I think Linux should stop supporting graphic systems? No. Same principle here. If you don't care about boot times then you should have no problem with people trying to change them.

Re:Whats wrong with init?

[Anonymous Coward]

You hit it in head. It's no about the statue thing. He just hates linux's way of doing things but has enough power to change linux into something akin of a microsoftian nightmare so on he goes with his astroturfing army. And red hat is happy because suddenly they control everything and it plays nicely with their plans of virtual machine domination in the commercial world. At the expense of sysadmins everywhere who want to have something other than black boxes.

Re:Whats wrong with init?

[Bronster]

"The issue with systemd: it reeks of a solution looking for a problem."

I dunno - I've rolled a bunch of stuff using daemontools, a bunch of stuff using other daemonisation techniques and a nasty complicated dependency tracking system on top of that - it's complex, but it works.

If there's a standard tool doing a significant part of that heavy lifting across all the linuxes, that's a big win in my book. I buy some of the "it's too complex" argument, but not enough to overthrow the benefits of being a standard part of my installs.

Which leaves security exposure, and that's an interesting question... but assuming it's not really awful, its ubiquity should get more eyes and more fixes than running something rare.

Re:Whats wrong with init?

[nabsltd]

If you don't care about boot times then you should have no problem with people trying to change them.

I wouldn't, if it didn't add hours to the install and config of a service that isn't available as a package from the distrubution.

And, even if a package is available, it's impossible to make a systemd dependency tree work correctly unless you install every package that might possibly be used. Based on other posts, this seems to be the assumption in the architechture of systemd.

As an example, if you have sendmail installed, it doesn't have to have clamav installed to work, and so the package doesn't have that dependency. Likewise, if you do have both installed, sendmail still can't have a systemd dependency on clamd running, because you might not want to use clamd to scan e-mail. But, if you do want that configuration, you need to muck about in dependency files that will be overwritten the next time you update one of the packages.

OTOH, with some other init system, all you need to do is add few lines to the sendmail init script to wait for the clamd socket to come into existence.

Re:Whats wrong with init?

[GPLHost-Thomas]

OpenRC is in Debian: https://packages.debian.org/ex...

And I will upload it to Sid soon.

And by the way, there has never been a declaration that Debian will support *only one* init system. Just that systemd will be the default for Jessie. Nothing more, nothing less. Anyone willing to help the Debian OpenRC team is welcome to do so (by developing OpenRC, testing it in Debian, writing runscripts, etc.).

Re:Whats wrong with init?

[Anonymous Coward]

The start-stop-daemon tool can write pid files. Even when using that functionality however, it won't know what happened if the binary started forks since start-stop-daemon can only track the immediate child of the start-stop-daemon process. Normally, the daemon generates its own pid file, and that pid file is given as an argument when using start-stop-daemon to stop the daemon. Heaven help you if that pid file only contains one of many processes actually started when starting the service. Also, what happens if the pic file is deleted?

I believe that systemd handles those problems much more gracefully.

like conceeding that air is necessary

[Virtucon]

I'm sorry but the systemd thing is really, really a mole hill when it comes to Ubuntu embracing things. From my perspective it doesn't matter what init scheme you use as long as it does it efficiently and allows you to augment things when you need to. Shit most Linux users don't even know what their distro's choice is for init scripting! Cripes you'd think that folks would have thought that the Vatican was now allowing electronic balloting and using Green Friendly e-smoke for electing the Pope or something with all this nonsensical whoopla.

Re:like conceeding that air is necessary

[raxx7]

Users rightfully do not care about what init system they use, as long as it works.
But making it work requires time and effort from some people. And we don't live in a world of infinite resources.

By announcing they're switching Ubuntu from Upstart to systemd, Ubuntu aligned themselves with the majority of the developer comunity and Ubuntu reduced the ammount of effort they and others developers have to put in to make it work efficiently as you said.
Ubuntu will not have to write and debug Upstart configuration files for services, they can just the share the same systemd files as Debian.
GUbuntu and KUbuntu developers will have less trouble to make Gnome Shell and KWin, which are moving towards somewhat depending on systemd, work on a Ubuntu derived distribution.

And that means they can actually spend time fixing other stuff.

Re:like conceeding that air is necessary

[joebok]

The Vatican is using green friendly e-smoke and electronic balloting??? Wow!! Now THAT is NEWS!!

However, I wonder what init system the voting station OS will use? That could be of critical importance.

Re:like conceeding that air is necessary

[causality]

Users rightfully do not care about what init system they use, as long as it works. But making it work requires time and effort from some people. And we don't live in a world of infinite resources.

By announcing they're switching Ubuntu from Upstart to systemd, Ubuntu aligned themselves with the majority of the developer comunity and Ubuntu reduced the ammount of effort they and others developers have to put in to make it work efficiently as you said. Ubuntu will not have to write and debug Upstart configuration files for services, they can just the share the same systemd files as Debian. GUbuntu and KUbuntu developers will have less trouble to make Gnome Shell and KWin, which are moving towards somewhat depending on systemd, work on a Ubuntu derived distribution.

And that means they can actually spend time fixing other stuff.

This is more like the kind of answer I was expecting to my earlier posts in this discussion. It makes a lot of sense. Thank you for that.

It's nice to seen an adult person give a reason that makes sense instead of getting all pissy that everyone doesn't already see it his or her way.

Re:like conceeding that air is necessary

[squiggleslash]

I don't know what Slashdot you're reading but the one I'm reading is packed with supportive comments about the decision. I think there's just relief that Shuttleworth hasn't decided to NIH something for once.

(Not that I'm particularly upset that they tried to do something different with Unity. GNOME 3 needed a good alternative, the problem was that Unity seems to be just as flawed, not with the principle of doing something. It'd be nice to see them stick with X.org rather than go Wayland, but they've also decided to do the "wrong alternative to wrong" again in Mir...)

Re:like conceeding that air is necessary

[Virtucon]

AFAIK it's Ubuntu, Venomous Vulture release.

Re:like conceeding that air is necessary

[Eunuchswear]

The Vatican is using green friendly e-smoke and electronic balloting??? Wow!! Now THAT is NEWS!!

The smoke comes from organic hay.

As for electronic voting - why bother? They're all in the same room (locked!) - electronic voting would just lead to fears that someone was hacking it from outside.

Re:like conceeding that air is necessary

[stub667]

Right, few people care about the init scheme. systemd would have had much less of a battle for acceptance if it was just an init scheme. The major objections seemed to be about all the other stuff it takes over and plans to take over.

Embedded uses something different anyway

[Anonymous Coward]

I don't think very much embedded stuff will ever use systemd. Most use System V or Busybox init or spin their own simpler version. If someone is using a general purpose install like Ubuntu for embedded work, they're doing it wrong right from the start.

Re:Embedded uses something different anyway

[skids]

It's actually a drain on embedded systems to do so much through shell scripting, having all those processes running scripts in an interpreted language. Systemd supposedly will allow a leaner build.

Re:Embedded uses something different anyway

[fishybell]

At a point when even the cheapest SoC has more processing power, memory, and storage space than your current desktop the cost of learning and using a custom system like Busybox will outweigh the benefit for many. For devices that need instant-on capabilities I don't think it's realistic to expect anything other than a custom init, but for the rest I expect programmers to programmers; that is, lazy.

Re:Embedded uses something different anyway

[dalias]

This is a fallacy. A shell script running on a non-bloated shell (e.g. Busybox ash) consumes less than 50k of dirty pages per instance. It would take at least 20-30 such scripts running to even come close to rivaling systemd's memory usage, and that's not even counting other resources systemd is consuming.

Re:Embedded uses something different anyway

[Anonymous Coward]

I don't think very much embedded stuff will ever use systemd..

I am using Angstrom, which uses systemd, for embedded stuff. Haven't had any problems with systemd, but haven't tried to do anything complex either. It gets stuff started at startup time, that's all I have needed.

Re:Embedded uses something different anyway

[Anonymous Coward]

I doubt there are many SoCs with more than 16GB ram and more than 8 processing cores.

Re:Embedded uses something different anyway

[Anonymous Coward]

Shell scripts are horribly inefficient and systemd is already being used in some embedded systems (BMW for instance).

Re:Embedded uses something different anyway

[Anonymous Coward]

...now.

Re:Embedded uses something different anyway

[Anonymous Coward]

s/Busybox/systemd/;

Re:Embedded uses something different anyway

[RR]

It's actually a drain on embedded systems to do so much through shell scripting, having all those processes running scripts in an interpreted language.

This is a fallacy. A shell script running on a non-bloated shell (e.g. Busybox ash) consumes less than 50k of dirty pages per instance. It would take at least 20-30 such scripts running to even come close to rivaling systemd's memory usage, and that's not even counting other resources systemd is consuming.

Memory isn't the only resource. (And if you're using Linux, you're already using a ton of memory.) Systemd brings standardized, concurrent, event-driven startup, so it takes less time to start up, both CPU time and wall clock time. For example, systemd's declarative unit files have much less boilerplate and take less effort to parse than SysV-style init scripts.

At this point, systemd has also been concentrating on correctness and functionality. They aren't even optimizing for speed and memory consumption, yet. It would be interesting if Busybox added a systemd-style init.

Re:Embedded uses something different anyway

[Zero__Kelvin]

"At a point when even the cheapest SoC has more processing power, memory, and storage space than your current desktop the cost of learning and using a custom system like Busybox will outweigh the benefit for many."

I'm afraid that isn't correct. At that point there is no advantage to not just using a standard distribution that uses systemd. You wouldn't use busybox on your desktop machine would you?

Re:Embedded uses something different anyway

[Zero__Kelvin]

Oh $h1t! I just realized I inverted what you said in my mind before posting my other reply. You are absolutely correct, and I apologize!

Re:Embedded uses something different anyway

[Zero__Kelvin]

Never mind!

Re:Embedded uses something different anyway

[Anonymous Coward]

If it would only take 20 to 30 scripts to match systemd, then systemd is already outperforming most out-of-the-box startup configurations.

Re:Embedded uses something different anyway

[DeSigna]

Systemd brings standardized, concurrent, event-driven startup, so it takes less time to start up, both CPU time and wall clock time. For example, systemd's declarative unit files have much less boilerplate and take less effort to parse than SysV-style init scripts.

So?

Embedded systems using lightweight shells already take only a handful of seconds to boot up with their handrolled initscripts. And even more so than most desktops and servers, that embedded unit is probably going to be turned on for years at a time without reboots.

I've nothing against systemd itself, beside not being very familiar with its internals and being slightly annoyed at having to remember to type "systemctl" instead of "service", but it's silly to position its most-touted benefit as being "quicker boot times". A lot of the secondary benefits, well, we've already got things like OpenRC, rsyslogd and grep.

I may also be a little miffed at having ported a ton of old style init support glue (for a bunch of RH Kickstart configs) to the comparatively poorly documented Upstart, and now I have to change them again for 7's systemd :|.

Re:Embedded uses something different anyway

[shutdown -p now]

Startup speed is simply not an issue anymore. Your typical server is supposed to be up most of the time, your typical desktop or mobile device is sleeping or suspended when it's not running, and your embedded device only has very few services that it needs to start, to the point where even SysV init is overkill and you're better off with rc.conf or something similar.

Re:Embedded uses something different anyway

[RR]

Startup speed is simply not an issue anymore. Your typical server is supposed to be up most of the time, your typical desktop or mobile device is sleeping or suspended when it's not running, and your embedded device only has very few services that it needs to start, to the point where even SysV init is overkill and you're better off with rc.conf or something similar.

That's incorrect.

The big excitement in servers is Elastic Compute. There, you do want servers that can boot up and shut down as quickly as possible, to handle varying demands. It seems that even Linux is considered to take too long, so some Linux kernel maintainers are making their own cloud OS that boots up even faster.

Desktops and mobiles do reboot sometimes. Fast booting was a major selling point for Unix during the age of The UNIX-HATERS Handbook. A bigger benefit for modern PCs is how systemd uses sockets and cgroups to control program state. And I thought the thread was about embedded.

There is more than one type of embedded device. In particular, I am annoyed at how home routers have progressed from, for example, the Netgear WGT624 which took about 15 seconds to boot, to now the Netgear R6300 which takes over a minute to respond to PING, and I'm not sure how much longer until it's fully functional. Sure, once it's configured and running, it's nice, but a typical setup could take several reboots and cause a lot of wasted time.

The R6300 has 128MB of flash and at least 128MB of RAM. That's a lot. Surely it can hold systemd.

Re:Embedded uses something different anyway

[Anonymous Coward]

> Shell scripts are horribly inefficient [...]

Things don't become truth just by repeating them over and over again. Shell script phobia is widespread among the Java tainted youth. It's just lack of knowledge and fear of the typeless and malleable.

Shell ain't for everything, and once a shell script surpasses a limit of --say-- 30 well-written lines, one should re-evaluate the approach.

But shell is *downright wonderful* as a glue between programs: this is a thing to take into account when designing said programs. Namely as building blocks and not as worlds in themselves. It takes some humilty to that (which is at the same time pride).

Go make the test and run a "hello world" in Java and bash. Which one was quicker? Thought so.

It can all be explained psychologically. Just take some meds.

Re:Embedded uses something different anyway

[Anonymous Coward]

Here. I did the measurements for you:

Java

tomas@rasputin:~/hello$ time java hello
Goodbye, Java!

real 0m2.043s
user 0m0.264s
sys 0m0.168s
tomas@rasputin:~/hello$ time java hello
Goodbye, Java!

real 0m0.182s
user 0m0.120s
sys 0m0.060s
tomas@rasputin:~/hello$

So 182 ms on warm caches.

bash

tomas@rasputin:~/hello$ time bash hello
Hello, bash

real 0m0.024s
user 0m0.000s
sys 0m0.004s
tomas@rasputin:~/hello$ time bash hello
Hello, bash

real 0m0.007s
user 0m0.004s
sys 0m0.004s

7 ms on warm cache. And bash ain't the fastest:

dash

tomas@rasputin:~/hello$ time dash hello
Hello, bash

real 0m0.004s
user 0m0.000s
sys 0m0.000s
tomas@rasputin:~/hello$ time dash hello
Hello, bash

real 0m0.004s
user 0m0.000s
sys 0m0.000s

So a factor of 25!

Now in C (default compile params, gcc in the abouts of 4.7):

C

tomas@rasputin:~/hello$ time ./hello-c
Hello, world!

real 0m0.003s
user 0m0.000s
sys 0m0.004s
tomas@rasputin:~/hello$ time ./hello-c
Hello, world!

real 0m0.003s
user 0m0.000s
sys 0m0.000s

So for smallish programs doing simple things (the "glue" thing), a shell isn't far from C (provided the interpreter is mapped in -- but it *is* mapped in on every Unixoid). And *orders of magnitude better* than e.g. Java. Would I try to write something like Lucene in shell? Hell, no (personally I wouldn't use Java either, but to each her own).

So go and stop spouting nonsense.

Re: Embedded uses something different anyway

[Anonymous Coward]

Embbed Yocto uses systemd, so you are incorrect. Fastboot is important and systemd provides a degree of parallel process startup. System boot up times on ARM less than 10 seconds with graphics.

Re:Embedded uses something different anyway

[Anonymous Coward]

And if you're using Linux, you're already using a ton of memory.

lolwut?

whats your definition of 'a ton'?

I've had a trimmed and toned kernel running in 16MB....I know thats not slim by 1980's standards, but this is the 21st century man!

Works for me

[Slashdot Parent]

I basically hate upstart, so bring it on, systemd.

Nevertheless, the decision is for systemd

[Threni]

Sentence fragment.

Re:Nevertheless, the decision is for systemd

[Eunuchswear]

matches fragmentary thought.

Re:Nevertheless, the decision is for systemd

[Anonymous Coward]

"Is" is the verb, "the decision" is the subject. There is no object, but one is not necessary. Is "I am for systemd." a sentence fragment?

Don't grammar nazi unless you can really hack it.

Yes, I used "grammar nazi" as a verb.

Stupidity is contagious

[gweihir]

That is the only explanation I can come up with for this. Personally, I am in the process of moving to Gentoo to avoid the systemd-plague.

Re:Stupidity is contagious

[Anonymous Coward]

What a well-reasoned, logical position you have taken. Couldn't be bothered to provide any rational argument behind why systemd is a plague, eh?

Re:Stupidity is contagious

[SargentDU]

systemd is also on gentoo, so you may have to resort to older distributions / source code.

Re:Stupidity is contagious

[gweihir]

It is there, but it is not mandatory.

Re:Stupidity is contagious

[gweihir]

The shortcomings of this monster are rather obvious to anybody halfway competent.

Re:Stupidity is contagious

[Anonymous Coward]

Better move to BSD. Gentoo already has systemd with Gnome depending on it. Even Slackware might make the move eventually, Patrick told it in an interview:

LQ) Right now, there are a number of potentially intrusive technical changes coming to some of the major distributions. How do you feel some of these will impact Linux in general and Slackware specifically? Are there any you would considering merging into Slackware? (55020 & tuxrules)

volkerdi) Yeah, I see a few things coming down the line that may cause a shakeup to our usual way of doing things, and could force Slackware to become, well, perhaps less UNIX-like. I guess the two big ones that are on the horizon are Wayland and systemd. Whether we end up using them or not remains to be seen. It's quite possible that we won't end up having a choice in the matter depending on how development that's out of our hands goes. It's hard to say whether moving to these technologies would be a good thing for Slackware overall. Concerning systemd, I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scripts that are readable, and I'm guessing that's what most Slackware users prefer too. I don't spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc., all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well. To the typical end user, if this results in a faster boot then mission accomplished. With udev being phased out in favor of systemd performing those tasks we'll have to make the decision at some point between whether we want to try to maintain udev ourselves, have systemd replace just udev's functions, or if we want the whole kit and caboodle. Wayland, by comparison, seems fairly innocuous, assuming that they'll be able to implement network transparency either directly or through some kind of add-on compatibility layer. Again, another thing that most desktop users don't have a lot of use for but many users can't do without. I like X11, and would probably stick with it if moving to Wayland meant losing that feature, even if Wayland's rendering method carried with it some benefits like reduced rendering artifacts or increased video performance. I guess we'll just have to see what the overall benefit is when it's far enough along to make such comparisons.

source: http://www.linuxquestions.org/questions/interviews-28/interview-with-patrick-volkerding-of-slackware-949029/

So, it looks like systemd is the future for Linux, until something better comes.
Of course, people who don't like that can still put together a distro with something else as PID1, it's still free software after all. But I seriously doubt the people who care with passion have enough manpower to propose a real alternative.

Re:Stupidity is contagious

[gweihir]

Gnome? Why would I use that?

Re:Stupidity is contagious

[Anonymous Coward]

Fuck you you triumphalist fuck.

I hate your systemd.

Re:Stupidity is contagious

[UnknowingFool]

Only if you blindly ignore all the advantages. Neither init or systemd will solve the world's hunger problem. The distros have decided for all the advantages to go with systemd. But they must be stupid not to see your point of view, right?

Re:Stupidity is contagious

[fgodfrey]

The distros are going with it presumably because they think they need it to turn Linux into a desktop or notebook OS. However, they seem to be ignoring the issues it presents for servers. Let's take my *THREE HOUR* debugging session on systemd yesterday. I had a netboot system up and running. Client boots from Server and mounts root filesystem from Server. I changed from Server A to Server B. Due to an NFSv4 vs. NFSv3 issue, Client could no longer mount the root filesystem read/write. Simple, right? It would've been with SysV init because the errors during the mount would've been spewed to the console and I would've seen them. What *actually* happened is that a bunch of services failed to start. Instead of spewing the error message, systemd "helpfully" told me to run "systemctl status" on the service to see the error message. Except that I never got to a login prompt due to the errors. And I couldn't mount the filesystem read/write so it lost the logs.

Two+ hours later, I managed to disable enough stuff to get to a login prompt where I was finally able to figure out what was going on (never did get systemctl to show me the logs, probably because they couldn't be written to disk and it doesn't seem to hold them in RAM).

Please explain to me what the advantage of systemd is again? Because I'm *REALLY* not seeing it. It took something that was trivial to figure out and made it astronomically difficult. I no longer have any idea what order my services start in or whether that order is repeatable. Yes, SysV init scripts were really long. But once you learned them, you realized that you only had to modify 5 or 6 lines of them to get a new service going. I have yet to figure out how to even create a service with systemd or how I figure out what I'm depending on.

In short, for a server, I have yet to see a single advantage of systemd over SysV init. Maybe I'm missing something and someone will enlighten me, but I'm extremely skeptical.

Am I just resistant to learning new things? Maybe, but learning stuff takes time and my time is money for my employer. So if I'm not getting a return on my investment of time (in new capabilities or reduced debugging time or *something*), why would I invest the time to become an expert on systemd?

Re:Stupidity is contagious

[Eunuchswear]

He's going to be pissed when Gentoo moves to systemd.

Hey! BSD! A new user!

Re:Stupidity is contagious

[GodWasAnAlien]

These:
http://ewontfix.com/14/

What exactly are the bounds of SystemD?
It touches every part of the system from the kernel to the UI.

https://en.wikipedia.org/wiki/...

Such an unbounded piece of software violates basic software engineering concepts, and the Unix tradition of tool simplicity.

Re:Stupidity is contagious

[Omicron32]

> I have yet to figure out how to even create a service with systemd or how I figure out what I'm depending on.

man systemd.profile

> Let's take my *THREE HOUR* debugging session on systemd yesterday. [...] It would've been [simple] with SysV init because the errors during the mount would've been spewed to the console and I would've seen them.

http://freedesktop.org/wiki/So...

30 seconds of Googling.

Not really sure what the problem is here other than your ignorance.

Re:Stupidity is contagious

[Omicron32]

Oops: man systemd.unit

Re:Stupidity is contagious

[Omicron32]

GNU coreutils is also on Gentoo... and Ubuntu, Debian, Arch, SUSE, etc, etc, etc.

Not avoiding that plague, are you?

Re:Stupidity is contagious

[Ash Vince]

In short, for a server, I have yet to see a single advantage of systemd over SysV init.

You are probably right, I always thought the advantage of systemd and and upstart was so that Linux desktops cold start matching Windows bootup times by starting lots of services in parallel. I guess the only time that benefits a server is the once a year you might actually need a reboot.

Re:Stupidity is contagious

[gweihir]

The shortcomings are show-stoppers. No advantages can compensate for them. And the main one, faster boot times? That is just a pathetic excuse. There is zero need for it, Linux boots fast enough. And in a server-setting, it is completely irrelevant anyways.

What systemd does is integrate a lot of things. That is exceedingly bad design and violated both UNIX philosophy and KISS. These two principles are there for a reason. Complex systems are hard to debug, hard to adjust and configure and generally far less stable than simple ones. With init, for example, it is quite possible that a single task fails or takes very long. Then you have to debug exactly one init script and its attached application. Everything is in plain sight. With systemd, you suddenly have to look at a complex mess of source code. Or take that systemd includes udev. Udev is pretty difficult to understand and debug on its own and these idiots _increase_ its complexity? WTF? Or take the binary logs. Never, ever will I accept binary logs. Logs must be clear and easy to manipulate (grep, sort, othr GNU text-utils), anything else is bound to be a problem and make any debugging harder. Then there is that the main systemd wannabe "king" refuses to make it portable, making Linux with systemd an island. That is so stupid, it defies all reason. There are also strong rumors that systemd project management is broken and all criticism is ignored or met with excessive hostility. The list goes on.

I do not know what went on behind the scenes when Debian decided (not final yet) to use systemd. But I do knot there was a lot of opposition to it and that opposition has not gone away. The way this was brought to a vote in the Debian technical committee could be called "underhanded".

Re:Stupidity is contagious

[gweihir]

Boot times are mostly irrelevant. You have them once a day, typically. Why people focus on this thing is beyond me.

Re:Stupidity is contagious

[gweihir]

It is even simpler: If it works, do not fix it. Systemd does solve problems that would not exist without it, and it does it badly. With stories like yours, I come more and more to the conclusion that the systemd designers are some semi-competent Windows programmers that have no clue what they are doing. I mean, not flushing error messages to console if that is the target left? I do not know how to solve this in a more stupid way. I need my serial cable regularly for those and usually things are easy to fix once use that. But if it does not flush to console, it will not flush to serial console either. Apparently the sytemd-cretins have never debugged a startup-problem.

Re:Stupidity is contagious

[0123456]

I guess the only time that benefits a server is the once a year you might actually need a reboot.

Ha-ha-ha. Our new HP servers take about six minutes to get out of the BIOS. Linux boot time is irrelevant in comparison.

Re:Stupidity is contagious

[Ash Vince]

Boot times are mostly irrelevant. You have them once a day, typically. Why people focus on this thing is beyond me.

I think they are irrelevant to most techies, yes as we have a habit of just leaving our PC's on even when not using them. In my case I powered my machine up this morning and have been pottering around all day with it on in the background. Ubuntu has always had the aim of creating an OS that can appeal to all though and that includes appealing to people like my missus downstairs. She would get annoyed if her laptop on the coffee table took longer than it does to boot since she turns it on and off as needed. Personally I use Mint so I guess my machines will end up on systemd too unless I ever decide I have enough time to move back to Gentoo.

I was more surprised when Debian announced they were moving to systemd since I always consider that more of a server OS, now that they have it makes perfect sense for Ubuntu to follow.

Re:Stupidity is contagious

[drJeckyll]

Gentoo already have systemd support, and you can use it if you like - http://wiki.gentoo.org/wiki/Sy...

Re:Stupidity is contagious

[UnknowingFool]

Systemd works better for desktops in theory and worse for servers. However, most Ubuntu is primarily aimed at desktop so I don't see the problem.

Re:Stupidity is contagious

[UnknowingFool]

Please explain to me what the advantage of systemd is again?

This took 30 seconds to google:

systemd:

• Fast boot time, mainly achieved due to starting services in parallell. This can also be achieved with SystemV init, but has to be done manually, while it is a product of dependency handling on systemd.
• Automatic dependency handling.
• Monitoring of started services with the ability to restart crashed services.
• Modules written in compiled languages, probably hard to debug.
• Tries to replace several system services, from the actual init over hardware recognition and session management to the logging service, and many more. Not the Unix way.

SystemV:

• Boot time depends on the admins optimizations.
• Due to its static dependency handling relies on a knowledgeable admin. Decide for yourself if you count that as advantage or not.
• Needs often some hacks to monitor services, services can easily escape the monitoring.
• Written as Shell scripts, so easy to debug and alter if necessary.
• Minimal approach, doesn't try to be the one super-service running the system.

Re:Stupidity is contagious

[UnknowingFool]

The shortcomings are show-stoppers. No advantages can compensate for them. And the main one, faster boot times? That is just a pathetic excuse. There is zero need for it, Linux boots fast enough. And in a server-setting, it is completely irrelevant anyways.

Your opinion. But never mind that people who have to handle whole distros have found that the disadvantages are not show-stoppers feel differently. So when is your distro coming out? Also, most people who run a server would not pick Ubuntu or Fedora or Gentoo as the distro to use. But let's ignore that too.

What systemd does is integrate a lot of things. That is exceedingly bad design and violated both UNIX philosophy and KISS.

It is doing things differently than Unix. So what? Linux has always done things that are not Unix. As for KISS, there's always a tradeoff when complexity is required. To handle the many new and different types of services that Linux will need, simplicity is not cutting it. There are a lot of hacks that have to be done in init (like parallelization) to make things work. Systemd has this built in.

With init, for example, it is quite possible that a single task fails or takes very long. Then you have to debug exactly one init script and its attached application.

Yes it will be harder to debug in systemd. It is designed to handle more than init can handle. That's the price you pay when you want to do things more complicated.

There are also strong rumors that systemd project management is broken and all criticism is ignored or met with excessive hostility. The list goes on.

Rumors and innuendo do not make for reasons.

I do not know what went on behind the scenes when Debian decided (not final yet) to use systemd. But I do knot there was a lot of opposition to it and that opposition has not gone away. The way this was brought to a vote in the Debian technical committee could be called "underhanded".

You do not know why Debian decided why they did but that hasn't stopped you from calling it underhanded and stupid. I see.

systemd violates the UNIX philosophy

[bzipitidoo]

The philosophy of modularity. Tools are many and small and simple, do one thing and do it well. But then, the Linux kernel also violates this principle.

There's also this seeming drive to make more tools dependent on systemd. Does udev really need to depend on systemd?

Wayland may be an example of an approach more in line with the UNIX philosophy. X has a lot of baggage that has become useless over the years. Lot of basic graphics functionality has moved into specialized graphics hardware.

Re:systemd violates the UNIX philosophy

[joejor]

Here's a pretty good treatise on the shortcomings of systemd: http://ewontfix.com/14/

Re:systemd violates the UNIX philosophy

[zixxt]

Amen!

Re:systemd violates the UNIX philosophy

[broken_chaos]

Wayland is actually one of the "new Linux" things that I'm interested in. I'm not getting rid of X anytime soon, but when Wayland has the tools, hardware support, etc. I need, I'll likely switch to it without any fuss. (For the curious, I use i3 as a window manager, and there's just no equivalent compositor for Wayland yet. None of my applications are GTK+3 or QT5, either, so I'd be using the X compatibility layer for essentially everything too.)

But systemd I really am not fond of. It's not an issue of being different (though that is some part of it), so much as the way it dictates so much of how you use things. It seems to touch every single part of your system on an ongoing basis, rather than just booting the system and staying out of the way. I sincerely doubt there would be as much distaste for it if it was just the init system part, rather than stuffing everything else in too.

Re:systemd violates the UNIX philosophy

[Anonymous Coward]

Does udev really need to depend on systemd?

Yes, and systemd needs to depend on journald, and vice versa, and PulseAudio and Gnome must depend on them, too. Ideally everything should depend on everything.

If you design your services well, with clear and separate responsibilities, modular design, and clearly defined interfaces, some people may choose not to use them. In fact, they may decide that it's poorly written, buggy unstable crap. They may try to replace them with services that work instead. Or if you accidentally produce something useful, they may try to run your stuff on other operating systems. All of this must be prevented.

Re:systemd violates the UNIX philosophy

[kreigiron]

If UNIX philosophy is an issue, Buy a Mac (or download your favorite BSD) and use an actual implementation of UNIX, let's remember that GNU's not UNIX, and Linux is UNIX-like, we cannot ask for anything that's never been promised.

Re:systemd violates the UNIX philosophy

[Anonymous Coward]

I agree. Its a monolithic tool.

Re:systemd violates the UNIX philosophy

[Anonymous Coward]

I quite agree with the idea of critical core places having an extremely simple and provably correct hyper-visor of sorts to hand off to and be configured by more complex, permitted to fault processes.

Re:systemd violates the UNIX philosophy

[Anonymous Coward]

Wayland is not UNIX philosophy of decoupled components. It combines display server, window manager, and composite manager, and hardcodes a lot of stuff X did on top of a generic protocol. X has some baggage (but not nearly as much as people believe), but this baggage is not useless: It is there for compatibility reasons! The cost of Wayland is high: To remove some minor amount of old code, you break decades of compatibility (or you keep all the code in the form of xwayland and preserve at least backwards compatibility with old clients - still breaking compatibility of new wayland clients with old xservers). It puzzles me that peope get excited about Wayland. It does not have any real advantage, but somehow is able to profit from the old myth that X is bloated.

Re:systemd violates the UNIX philosophy

[Wdomburg]

You realize, of course, that systemd bears many similarities to launchd on MacOS X, which " essentially a replacement for init, rc, init.d script, rc.d script, SystemStarter, inetd / xinetd, crond / atd, [and] watchdogd"?

Re:systemd violates the UNIX philosophy

[Anonymous Coward]

Really? loginctl does't do /sbin/init. systemd doesn't do loginctl, one tool in it does it, just that, and does it well. Same for journalctl, etc... What's your point, really? Trolling? :)

CENSORED $ rpm -ql systemd | egrep /usr/s?bin /usr/bin/bootctl /usr/bin/hostnamectl /usr/bin/journalctl /usr/bin/kernel-install /usr/bin/localectl /usr/bin/loginctl /usr/bin/systemctl /usr/bin/systemd /usr/bin/systemd-analyze /usr/bin/systemd-ask-password /usr/bin/systemd-cat /usr/bin/systemd-cgls /usr/bin/systemd-cgtop /usr/bin/systemd-coredumpctl /usr/bin/systemd-delta /usr/bin/systemd-detect-virt /usr/bin/systemd-inhibit /usr/bin/systemd-loginctl /usr/bin/systemd-machine-id-setup /usr/bin/systemd-notify /usr/bin/systemd-nspawn /usr/bin/systemd-stdio-bridge /usr/bin/systemd-tmpfiles /usr/bin/systemd-tty-ask-password-agent /usr/bin/timedatectl /usr/bin/udevadm /usr/sbin/halt /usr/sbin/init /usr/sbin/poweroff /usr/sbin/reboot /usr/sbin/runlevel /usr/sbin/shutdown /usr/sbin/telinit /usr/sbin/udevadm

Why I don't like systemd:

[wonkey_monkey]

service is a word. systemctl isn't, and it's 50% more characters to type, too.

Re:Why I don't like systemd:

[Anonymous Coward]

put this line in your .bashrc file

alias service='systemctl'

Re:Why I don't like systemd:

[causality]

service is a word. systemctl isn't, and it's 50% more characters to type, too.

I can only imagine your irritation at using non-words like "rm", "cd", "ln", and "ls". At least they're short?

Re:Why I don't like systemd:

[Trepidity]

My guess is it's a takeoff on the classic sysctl.

Re:Why I don't like systemd:

[Eunuchswear]

The guy's an idiot. He probably has a .cshrc

Re:Why I don't like systemd:

[fnj]

Have you actually tried that? Better make service a shell script, not a simple alias. The two commands have different syntax.

service SCRIPT COMMAND [OPTIONS]

systemctl [OPTIONS...] COMMAND [NAME...]

I considered writing such a translating script, but really, why get trapped in the past? I can see making sc an alias for systemctl though.

Re:Why I don't like systemd:

[Anonymous Coward]

Just alias it to "scuttle" and be done with it.

why not the new thing?

[dAzED1]

There's this new thing called "init.d" which makes things really simple - you can start a system up and step through things, and though the boot takes 5 seconds instead of 1 second, that isn't really a problem.

Once I read the original post about systemd, and all the other let's-invent-a-problem-to-fix nonsense surrounding init.d, I literally hung up my hat and stopped being a syseng. I was a unix guy starting in 93, so it was probably time anyway, but it was the straw that broke my back, as it were.As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. I especially "loved" this line: As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. No. A good init system does it reliably, with no drama and no politics. A good init system allows one to easily determine the state of a system, and doesn't assume things like GUIs and such. A good unix init system does all this with commands which can be piped and parsed easily with grep and awk - two things the original post about systemd actually complains about. The idea that a unix person would complain about grep and awk was so mind-boggling to me that...well, I just hung up the hat. You did all this nonsense, just to save a few seconds? Because what, the only thing linux is used for, is laptops? Meh.

Re:why not the new thing?

[dAzED1]

oh boo, slashdot dropped the pre tag? Dorks. "As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast." = that was a quote from that original post about systemd

Re:why not the new thing?

[jbolden]

No they did all that nonsense to have features like monitoring and recovery that init.d didn't have. If a daemon has problems and needs to restart itself how does it do that? Heck if you really mean init.d and not xinit.d how does a system support triggers for hundreds or thousands of daemons most of which run very infrequently?

Re:why not the new thing?

[broken_chaos]

If a daemon has problems and needs to restart itself how does it do that?

...Monit? runit? Two completely different approaches to service monitoring, one not even in an init system. And there are more (s6, daemontools, etc.).

hundreds or thousands of daemons

...What the heck are you running that puts thousands of daemons on a single server? If you're doing something this large, you might want to consider virtualization. Thousands of daemons is a gigantic attack surface to have on a single system, and a mess if something were to go wrong with one of them that takes down everything.

Re:why not the new thing?

[Anonymous Coward]

Wow. Excellent critique. No upgrades without reboot? I don't think so. I'm sticking with Sysv.

Re:why not the new thing?

[Anonymous Coward]

At least the BSDs can remain stable, while Linux pursues faster unstable boot times.

Re:why not the new thing?

[Anonymous Coward]

This. This this this.

And in case anyone wants justification for dAzED1's comments, I recommend you read (not skim) the analysis done by the s6 folks, where they review each type of init methodology and explain the problems with all of them:

http://skarnet.org/software/s6/why.html

P.S. -- Sad that not a single *IX (BSD or Linux) has bothered to look into porting OpenIndiana/Solaris SMF. It's fantastic and puts a lot of things to shame. You get the best of both worlds with it. Trust me: once you start using it, you really can't look at services the same ever again. And yes, the way it works is fully documented (man pages are very clear, although more examples could be added) and does include an API (I'm sure that would make Lennart masturbate furiously). svc.startd and svc.configd are relevant to SMF as well.

Re:why not the new thing?

[Anonymous Coward]

If systemd has a problem and dies ( PID 1 ) what happens? kernel panic!

if systemd is updateed what happens? A windows required reboot!

Nuff said

Re:why not the new thing?

[Eunuchswear]

I was a unix guy starting in 93

Newb.

Re:why not the new thing?

[tokiko]

Correction: The original post about systemd was not complaining about using grep and awk on the scripts. The complaint was that the scripts where calling these commands way too often during the normal boot up procedure.

On my system the scripts in /etc/init.d call grep at least 77 times. awk is called 92 times, cut 23 and sed 74. Every time those commands (and others) are called, a process is spawned, the libraries searched, some start-up stuff like i18n and so on set up and more.

Re:why not the new thing?

[thegarbz]

As mentioned, the central responsibility of an init system is to bring up userspace.

Yes except that's not what init is. Init for better or worse is a single control system that manages daemons. It would be fine if it were a script that managed the initial startup and then disappeared off into the ether, but no manually starting something like Apache produces different results than typing service httpd start.

As a central management system that controls services it needs to take into account all actions of the system NOT JUST STARTUP. If I pull my network cable out, what happens to services that depend on network? If I put my computer to sleep and wake it on a different network, what happens to services that depend on location.

That is why EVERY replacement for init has placed emphasis on event driven service management, because managing services is more than startup, and init is attempting to do just that... poorly.

Re:why not the new thing?

[mab]

"if systemd is updateed what happens? A windows required reboot!"

systemctl daemon-reexec

Re:why not the new thing?

[mab]

systemctl daemon-reexec

Re:why not the new thing?

[Anonymous Coward]

That's not what PRE is for in any case, mate. You'll be wanting QUOTE or BLOCKQUOTE for that.

(And the Preview button that you didn't bother using.)

Re:why not the new thing?

[Bronster]

Fuck yeah. If I make major software changes on a server, I damn well want to reboot it and make sure it can bootstrap from scratch.

Actually, unless it was a really minor fix, I'd probably want to reinstall it from scratch. That takes ~10 minutes (bit longer these days because hardware takes so bloody long to init).

That way I know I haven't built a multi-tentacled monster of a system with cross dependencies which will never start ever again. You already need a failover plan for when (not if) you have a hardware failure, so you may as well be testing it frequently by going through said steps - and a significant upgrade is a good time to do it.

This idea of upgrading everything in random order and restarting just the affected services doesn't scale. Reinstalls all the way, baby.

Re:why not the new thing?

[aliquis]

"When I was young we pinged each other using a stick, and we fingered each other using nothing but our fingers!"

Re:why not the new thing?

[dAzED1]

You're right, it's just easy. As for the preview - when forced to do it every time, it can become something one ignores. All this yammering about "beta" and I'm still pining for the previous version of slashdot :P

Re:why not the new thing?

[Samizdata]

Stupid newbs and their sticks. We used ROCKS for pings, and WE LIKED IT!

Re:why not the new thing?

[Anonymous Coward]

hundreds or thousands of daemons

They call it hell for a reason.

Re:

[binarylarry]

Well fuck it, lets rewrite the Linux kernel in bash!

about time

[Anonymous Coward]

ubuntu has not been so cutting edge anymore. maintaining the rc was so 80's. easy to monitor,simple to recover, loggging, vm friendly can't think why waited so long

Re:

[Anonymous Coward]

Bah, VB6!

I was shocked, just shocked.

[Anonymous Coward]

I was immediately surprised to read this. I just couldn't believe it. I read it a couple of times to make sure I read it right. I just can't believe people still use *buntu.

Re:I was shocked, just shocked.

[Anonymous Coward]

Yes they do. It is based on debian (+) and while vanilla ubuntu is strange, then it's derivates like mint, kubuntu and friends just plain rock. And at the same time they don't break things that already work in ubuntu, such as sane support for propietary firmware and software (ati and nvidia cards, flash, libdvdcss2 etc).

Nuts, upstart syntax is so easy

[exabrial]

I really like upstart. The scripts are stupidly easy to write and understand, and the syntax is plain english.

Actually that's the only reason I like upstart. Maybe with Ubuntu onboard with systemd we can get an alternate, easier-to-use syntax than the default systemd.

Re:Nuts, upstart syntax is so easy

[Rich0]

Actually that's the only reason I like upstart. Maybe with Ubuntu onboard with systemd we can get an alternate, easier-to-use syntax than the default systemd.

Well, one of the advantages of systemd is that the unit files are more about describing the necessary configuration settings needed to start a service, and less about writing a program to just do it. It is like the difference between writing a configuration file for Postfix vs Sendmail. The config file tells systemd what to do, not how to do it. It is possible to call a bash script, but this is more for cases when you really need flexibility - it isn't used just to launch a daemon with a few options and capture the PID.

It should be very straightforward to make a unit editor that just wraps a GUI around editing unit files with helpful field labels, online help, good templates/defaults and so on.

Re:Nuts, upstart syntax is so easy

[Anonymous Coward]

Upstart is in fact too stupid to deal with the case of launching daemons that launch other daemons. That is a very common use case for lots of legacy and non-free software (i.e., the kind of software that you can't just alter its behavior). So Upstart is really a non-starter. Good riddance. Can't comment on systemd though, haven't tried it yet.

Re:Nuts, upstart syntax is so easy

[qu33ksilver]

Yea well I am also a bit skeptic about how systemd will turn out. I have used upstart extensively. Do you know if all the event like functionality in upstart is available in systemd as well ?

Re:Nuts, upstart syntax is so easy

[Rich0]

I believe so, but I think it is more dependency-driven. That is, instead of writing a bunch of rules for what happens when the net goes down, you just specify what depends on the net, and so on. That said, the only device I have that runs upstart is a Chromebook, so I haven't really spent time studying it. I've run systemd on a few things, but none of them really benefit from event-driven service management.

who uses run-levels?

[Anonymous Coward]

Well, the BIG problem is maintenance. SysV scripts have both a S and K variant on when to run when switching levels, and you can bet very few people have it properly set up if you do switch levels.

While I'm an Linux admin now (and previously did a lot of Solaris stuff), I've also had a lot of experience with BSD.

There are three states that most systems are in:
* starting up
* shutting down
* single-user
* multi-user

I think BSD got it right in this regard as the extra complexity of run-levels isn't use much (if it at all).

Re:who uses run-levels?

[Anonymous Coward]

You and I have a different definition of 3 by the look of it...

Re:who uses run-levels?

[Anonymous Coward]

You are certainly not a mathematician...

Re:who uses run-levels?

[Qzukk]

That's ok, his numbering is the same as sysv, thanks to rc.S

Re:who uses run-levels?

[dentin]

In my systems, it's even easier: starting up, shutting down, and running. If I want a gui, I log in on a tty and run xinit. The only reason I even know what run level I'm in (3) is because the first thing I do on new systems is edit inittab to start up 20 virtual terminals so I have a proper programming environment.

In the 18 years I've been running linux, I've never seen an actual need for run level 5.

Granted, I'm not a sysadmin for other people or support other users on my box, but if I were, I'd probably expect them to log in at a tty and fire up X manually as well. This is why I would probably not be a good sysadmin.

Re:who uses run-levels?

[Zontar The Mindless]

And you are certainly not a member of the Spanish Inquisition. Count yourself even.

Re:Sigh.

[caseih]

Yes if you think systemd is bad, either rip it out on your machine or roll your own distro. Or move to FreeBSD. It's available now, and it runs great. So no need to whine. Just move to an operating system that fits your personal parameters. More likely you'll stick with your current distro and whine and moan about something that you don't well understand.

On the desktop side of things, I've been watching Linux struggle for years to do simple things like deal with removable media and USB devices. For a while there was hal, then udev, and now systemd. And finally things are actually working, and working rather well. Mostly thanks to udev, but systemd now builds on that. I know many people don't mind manually mounting devices and loading modules to make usb devices work (I don't mind, really). But it's nice to have things automatically work.

And really systemd on the service isn't that bad an idea either. Fine-grained logging is very useful and conventional syslog is still available and will always be there. Process supervision is something that's been needed for a long while now.

Fuck yes.

[Anonymous Coward]

I didn't see this coming. This is a massive boon. I was planning to jump ship to Debian as I was fully expecting Ubuntu to go all NIH and stick with Upstart.

I think Upstart is better than sysvinit, but I've had serious trouble as there are several things it simply can't do, and could never do, unless perhaps it got cgroup tracking support (and it still doesn't have that). Meanwhile, systemd came out of nowhere and - I tried it, and it was significantly better for what I needed, and that is server-side stuff too.

This is a very encouraging decision. It's too late for 14.04 LTS, but the next LTS should have it I think.

This should also replace all the scripts in the initramfs. At the moment, that's a bit of a pain, in both Debian and Ubuntu, and Ubuntu wanted to move Upstart into the initramfs. This should pre-empt that and properly deprecate Upstart.

Still, thanks to the people behind Upstart for an interesting approach. I can't help but feel that it does things the wrong way round though, and that's still the case even now. People hate Lennart, but systemd is damn good.

Wasn't there a revote?

[MurukeshM]

A few mails down the line, I saw someone (Ian Jackson, I think), call for a vote to depose Bdale as the TC chairman, and another vote with more options. The mail thread went on and on...
Can anyone summarize what happened then? Is Shuttleworth premature in this decision?

Re:Wasn't there a revote?

[Rich0]

I suspect he's trying to put pressure on everybody to quit with the soap opera and just go with systemd. He'd have probably preferred it if the ctte went with upstart, but I think half the linux world is scratching their head as half the debate seems to be about procedural nonsense and not the merits of the various init systems.

Sure, I can get the arguments about simplicity vs functionality and the unix way and all that. What I don't get is arguments about how the proposals are written, deposing chairs, and that sort of thing. Just pick an init system already, or decide to support both!

Re:

[Anonymous Coward]

"You mean you don't love me anymore?" sobbed PHP.

Variety was good

[Anonymous Coward]

Upstart was nice. Maybe if they release it under a BSD license some other project will pick it up. I am hoping to see something come out from OpenLaunchd though.

Re:

[F.Ultra]

Won't work, you can only build ip address tracking applications in Visual Basic

SystemVd - beware!

[Freshly Exhumed]

I got SystemVd on vacation in Thailand and now I'll never be able to spawn child processes again.

How do we stop this?

[Anonymous Coward]

How do we stop debian and ubuntu from forcing systemd.

The systemd people are true assholes. They force their way.
If I ever met any of them I would beat them bloody.

Is there any way to stop them?
Linux IS about choice.

You're not ALLOWED to stick with Sysv

[Anonymous Coward]

You're not ALLOWED to stick with Sysv. The systemd fucks in debian, arch, so on and so one won't allow it.

This really calls for a social solution. Hunt them down, beat them up. Keep doing it till they quit their forcing of systemd on everyone.

Re:

[nicolastheadept]

The truth is I never loved you

takes advantage of available resources

[raymorris]

Current systems, even phones, have dual and quad core processors. That means the existing hardware can run four threads on the CPU simultaneously, or about 16 active processes. System V runs one process at a time, meaning it's only using 6% of the hardware's capability.

Systemd, on the other hand, runs several processes at once, getting things done faster by making use of post-1995 hardware.

You say you don't see point of changes that take advantage of modern hardware. You only really benefit from 64 bit if you have more than 2GB of RAM. Does that mean 64 bit is silly?

Re:takes advantage of available resources

[Kremmy]

I say you're wrong because we don't need systemd to do that. No, we don't, because it's been possible to multiplex the SysV style init for ages. My debian server does it, with a slow SSD, and the results are beautiful. I'm all about taking advantage of modern hardware, but you're seriously talking about rewriting init because you don't want to use one of the pre-existing options for multiplexing the start up process. That's silly.

Re:takes advantage of available resources

[Kremmy]

As for 64-bit, one thing I've been thinking about recently is that x32 ABI and the potential uses for it. x32 in this case is a way to compile 32-bit programs into native 64-bit applications using a virtual 4GB memory space, while taking advantage of the greater number of registers the x86-64 platform provides. I feel like this would go incredibly well with the multitude of barebones, lightweight, low memory VPS systems that are about today. That could theoretically provide some nice performance increases in any case where you don't need full 64bit memory space (which is basically everything a virtual private server is being used for). Unfortunately there seems to not be much attention being given to the idea...

Re:takes advantage of available resources

[ultranova]

There is little attention given to the idea because it's a bad idea. The only advantage x32 gets you is smaller pointers. That's nice, but unless your data structures have a fatal case of pointeritis it's pretty much pointless, and if they have, your program is going to be a slow memory hog no matter what.

Also, 64-bit virtual memory space allows such niceties as memory mapping large files, thus working on them directly on the cache rather than duplicating data in an in-application buffer.

Re:takes advantage of available resources

[Blaskowicz]

But maybe you want to run slow memory hogs with pointeritis?, like interpreted dynamic languages and their runtime.

Re:takes advantage of available resources

[ultranova]

But maybe you want to run slow memory hogs with pointeritis?, like interpreted dynamic languages and their runtime.

If you do, and still care about pointer-size optimizations, then clearly your quest for performance is extremely serious and well-informed and should be treated that way by kernel and distribution makers.

Re:takes advantage of available resources

[Blaskowicz]

LOL, but there were all those comments on slashdot that the Silicon Valley is now infested by hipsters who refuse to take their fedora off and only know "Ruby on Rails!!!".
Sure, just run on i686 and you have the memory savings already.

Re:takes advantage of available resources

[Anonymous Coward]

Current systems, even phones, have dual and quad core processors. That means the existing hardware can run four threads on the CPU simultaneously, or about 16 active processes.

Tangential nitpick: there aren't any mass market CPUs which do four threads per CPU core. The only vendor selling multithreaded CPU cores is Intel, and all of their multithreaded consumer products (and even almost all their server / HPC products) are limited to two threads per core.

(I maybe shouldn't say "only" since AMD arguably does 2-way multithreaded CPU cores in some product lines too. However, they choose to market each hardware thread as a "core", so if you buy an 8-core AMD CPU you're getting eight threads. This is partially about marketing trying to inflate the core count, and partially because AMD's approach to 2-way multithreading is a bit different from Intel's. Intel shares nearly everything between the two threads, with decisions about resource allocation made on the fly. AMD uses more static partitioning -- most notably, there are two clusters of integer execution units with each cluster dedicated to one thread.)

Other Linux distros been using it over a year now.

[Anonymous Coward]

Arch switched over a year ago, and the world is still here. Improvise, Adapt and Overcome.

is this the real life

[Anonymous Coward]

or is this just fantasy?

UNIX philosophy is dead

[Anonymous Coward]

The small and simple tools just don't mesh well enough for the more complicated problems.

http://lwn.net/Articles/576078/

systemd: broken by design

[trek00]

a really interesting reading: http://ewontfix.com/14/

Re:systemd: broken by design

[Samizdata]

Mkay, can we PLEASE stop spamming this link? Yes, it is quite a good article, but you guys are reposting it more than "obligatory" XKCDs. or anti-Beta comments...

Scroll, scroll....

"Hey guys, check out this link!

Scroll, scroll....

Hey, read this article on why systemd is bad (same link)

Scroll, scroll...

Did you read this about the weaknesses of systemd? (Oh, look, the SAME link!)

Wash, rinse, repeat

Some of us actually read the entire comment section...

Unity Bytes

[sdinfoserv]

Shuttleworth ... Take heed from ... well ... everyone and dump Unity.

Re:

[Dishevel]

The real truth is you are completely unlovable.

Next is the turn for Wayland/Mir

[pronuncer]

In Wayland vs Mir debate. I predict Debian will choose Wayland, and so is Ubuntu.

Re:Sigh.

[koinu]

As a FreeBSD user, I laugh here silently about all your Linux problems. It's funny to see Linux distributions still use this SystemV crap, when everyone else already offers modern solutions for this. Linux does not even have an adequate devd/devfs solution, redesigned the dev-system several times and it is still bad. Now you get what you deserve... systemd and we can even laugh harder at you.

The only thing that hurts is probably that systemd might become the next hald oder consolekit which costed everyone years of development in wrong direction.

Sometimes, it would make sense to take a look at how others solve problems and learn from it (instead of re-inventing the wheel wrong the 4th time).

Car analogy

[zigfreed]

Init systems are like the starter motor and gear shift of the system. They are not designed to give feedback to the operator since most drivers can hear the clanking and do something about it. SystemD is like the dashboard and steering column with an integrated starter motor. It's got the gear shift built in and some lights that you can sometimes see when you look at it. In essence it is tuned to the motor (kernel) and faster than trying to guess where the clunking is coming from.

You choose systemD because you want the convenience of a dashboard and none of the alternatives considered that part of the design.

Re:

[TheRealDevTrash]

I did this in 2011. It's still uploading though.

Re:Sigh.

[mab]

FreeBSD should have launchd soon

Nice astroturfing

[Anonymous Coward]

Systemd does nothing that could not be achieved before with existing tools without the cost of obscurity that the cancerous systemd brings with it. It's horrible for proper servers.

> Learn to love systemd

No thank you if I wanted to go the microsoft route I'd boot a windows box.

It's a solution alright

[Anonymous Coward]

I'll explain you what is wrong with the existing inits and the already existing working tools that can be configured to do what systemd does, but in a less invasive, more respectful and transparent way.

Systemd exists as a solution because someone likes big "services" (since when do we have services) that take over the system and handle everything. According to his words. Systemd exists because it is C. C is this magical language that transforms something from being a shell kludge to a "proper solution". Even if they do the shit systemd does. Systemd exists because it gives leverage of the mainstream linux ecosystem to ONE company, and does it in a way that is the closest you can get to close: compiled code as opposed to shell. And systemd exists because newbies disparage mentions of 'systemd breaking the unix philosophy' without knowing what it means and thinking people don't like systemd because its new and new must be better. Systemd exists because they thought they could shove it down our throats.

If they wanted to do an init system they would have done it. They wanted to do something overarching. Embracing.

> "everyone else is adopting it as the new standard and it will be increasingly difficult to go against that standard."

Pretty clear, isn't it.

No a dogma thing

[Anonymous Coward]

Note the problem with not following the Unix philosophy is not a dogma thing. I don't care about what crap goes on over desktops, but I want my servers robust, reliable and simple.

We have bigger problems

[Anonymous Coward]

If this page you link is news to most people pushing for systemd we clearly have problems in Linuxland. And given this thread and the other threads from the systemd zealots, it is clear they have bloody clue. I'm sure Bill Gates is cackling with glee as he sips mojitos.

Re:Sigh.

[shutdown -p now]

The big problem with systemd is that it is trying very hard to make itself a non-replaceable component. Gnome effectively depends on it now, for example, and with udev being merged into it you basically can't avoid systemd without forking udev (which some Gentoo guys are trying to do). It also exposes public DBus APIs and a wrapper lib that's intended to be used by daemons to e.g. report lifecycle events, which obviously makes them systemd-specific. And the developer of systemd is actively campaigning for people to write Linux-specific and systemd-specific code.

So long term, we're looking at a landscape where any distro not on systemd is marginalized (because they are incompatible with at least one of the two major DEs and a bunch of other software, have to author their own startup scripts from scratch etc). FreeBSD would be marginalized even further if Poettering's idea of heavily relying on Linux-specific features is widely adopted. So overall choice would be restricted.

This isn't to say that the systemd doesn't solve real problems. The question is whether it solves them in the right way, and whether the price you have to pay for it is worth the benefits. There are other systems out there that try to solve the same problems by different means, sacrificing some things but avoiding creeping dependencies throughout the software ecosystem and overall complexity. OpenRC, for example.

/etc/portage/package.mask

[Anonymous Coward]

#shit
>=sys-boot/grub-2.0
media-sound/pulseaudio
sys-apps/systemd

Re:Sigh.

[Anonymous Coward]

Yes if you think systemd is bad, either rip it out on your machine or roll your own distro. Or move to FreeBSD. It's available now, and it runs great. So no need to whine. Just move to an operating system that fits your personal parameters. More likely you'll stick with your current distro and whine and moan about something that you don't well understand.

On the desktop side of things, I've been watching Linux struggle for years to do simple things like deal with removable media and USB devices. For a while there was hal, then udev, and now systemd. And finally things are actually working, and working rather well. Mostly thanks to udev, but systemd now builds on that. I know many people don't mind manually mounting devices and loading modules to make usb devices work (I don't mind, really). But it's nice to have things automatically work.

And really systemd on the service isn't that bad an idea either. Fine-grained logging is very useful and conventional syslog is still available and will always be there. Process supervision is something that's been needed for a long while now.

Typical slashtard #2

So where are the XML weenies?

[Anonymous Coward]

BINARY log files?! They should be hopping mad about this.

A huge monolithic init... hmmm... also sounds like a huge monolithic, um, kernel... right?
How many parts of the running system could be just huge monolithic pieces?

Then, if you start to subdivide them for ease of maintenance and scope, and modularize,
do you end up with the equivalent of a microkernel?! Or, maybe stuff could all be done with
kernel modules?! Nothing could possibly go wrong with that.

Then there is the bleating that we have oodles of cpu horsepower and memory so...
why not *WASTE* it?! Am I reading that right?

Some talk of the Unix philosophy... somebody please post it, in full, for the record.

Hackable

[Anonymous Coward]

I think *hackable* is the most important reason I'll avoid systemd like the plague.

The second most important reason is its community, which comes across like a bunch of thugs.

Solaris SMF

[Anonymous Coward]

Have you read about the systemd creator on he internet? He talks about Solaris SMF frequently. systemd is very similar to SMF. Someone said Linux devs has the Not-Invented-Here syndrome, so they recode everything. Couldnt he have just ported SMF to Linux, just like ZFS has been ported?

Re:

[Man Eating Duck]

Won't work, you can only build ip address tracking applications in Visual Basic

Yes, you simply create a GUI interface using VB :)

Re:Xubuntu 13.04 Live CD is already running system

[putaro]

But it's so much more fun to rewrite from scratch!

4 threads on CPU = many processes running

[raymorris]

I think you read that sentence backwards. I said four threads on the CPU. A quad core processor can of course do at least four threads.

Also, four threads on the CPU means there are probably at least a dozen processes waiting on IO. Four threads active on the CPU, sixteen processes active on the system.

Versus one active process for System V since it runs them sequentially.