Slashdot Mirror
Debian To Replace SysVinit, Switch To Systemd Or Upstart
An anonymous reader writes "Debian has been one of the last holdouts using SysVinit over a modern init system, but now after much discussion amongst Debian developers, they are deciding whether to support systemd or Upstart as their default init system. The Debian technical committee has been asked to vote on which init system to use, which could swing in favor of using Upstart due to the Canonical bias present on the committee."
I fucking hate this new system. Its a mess of scripts that call on more scripts. Its such a pain in the ass now if you want to have a program run when the system starts. Gone are the days of just adding a line to /etc/rc.local
Only the State obtains its revenue by coercion. - Murray Rothbard
Init would have been my pick, but I still hope this works out well for them.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Why not keep sysvinit and switch to OpenRC for managing the init scripts?
Actually, that's how sysv init works. To get a program started by systemd you have to create a service file full of magic commands and put it in the magic systemd directory. Then you have to type systemctl --abracadabra enable yourservicename.service. Then you have to go and add an [install] section to your service file, because nobody actually remembers that you have to write one or how to do it. Then you do the systemctl again. Then you check the log files to see if the thing actually started, because nothing gets output to the console during boot (except the filesystem mount messages and the big fat warning that my root fs is readonly).
On a Gentoo box, and it should still be starting via sysvinit.
My #1 reason for keeping it installed is standardization:
All the BSDs use a similiar system, all the legacy UNIXes do as well, as do all my linux installs that are more than 2 years old.
Additionally I have had *NO* problems with it in like 15 years that weren't caused by user error, or distro error. Systemd on the other hand rendered my system hung or inoperable on more than a few occasions when it first became popular, as has udev by itself. There's something to be said for 'windows-like' functionality, but all the subsystems that have been getting added to linux to provide it are proving messy, unmaintainable, and even more prone to 'unidirectional grading' (it used to be you could have both newer and older kernels, even across major versions running. Nowadays you're lucky if the minor versions don't break things over the span of two months. Anyone here remember having 1.2 installs running 2.0? Or 2.0 with a 2.2 kernel? Or 2.2/2.4? The only major issues you had were if you used ipchains/tables/ipfwadm and had to migrate your settings. And there was almost always legacy support for most or all of a major version change.)
Honestly with the way linux is going nowadays, as well as the various *BSDs, I'm considering very strongly migrating to another platform. If you change what people are used to too much, there's far far FAR less incentive for them not to try something totally new rather than bungling themselves up with half remembered details about how their *FORMER* version of the system operates. Much like happened with WinXP/Vista/7/8.)
Not that many people will agree with this assessment.
The problem with sysvinit is that 95% of daemons just need a common set of actions to start/stop them, and sysvinit tend to handle this by writing bash scripts starting from a skeleton.
So maybe for one daemon you can set a config setting to make it use ionice, and for another you can't, simply because in one script a bit of extra functionality was written.
For the most part systemd makes a config file into a config file, not an executable. Sure, you can run a script if you have to, but 99% of the time you don't need to.
In fact, there is no reason you couldn't write a sysvinit script that takes in a systemd unit as a config file and starts/stops the corresponding service. That would be a great way to transition - switch your bash scripts to unit files gradually and then swap out the init system.
It seems like I'm the only person on here who thinks this, but I really can't wait for the switch to happen. Upstart scripts are unbelievably easy to write when compared with init scripts. For one thing, they don't require massive amounts of boilerplate code. For another, they are relatively easy to manage and execute.
Just the other day I was trying to set up a couple of machines running deluge as a daemon. The Ubuntu machines took me 10 minutes tops. The remaining debian one had me in init script hell for an hour or more...
We want to change to "that" because basic idea is a good one. The ability to start services in parallel, socket activation, and cgroups for process group management are all good things. The problem with systemd is not so much these ideas, but the implementation. To put it bluntly, the developers are all "superstar" jerks who wouldn't know usability if it hit them over the head.
They designed an ugly interface with way too much automatic magic that no doubt is perfectly obvious and correct to them, but abstruse and incomprehensible to anybody outside their little circle. Then they wrote a couple of "howto" articles on complex sysadmin tasks that almost nobody has to do, and declared documentation complete. To do a simple task, like writing a service file, or God forbid, changing the getty program you want to use, requires a monumental effort of sifting through disconnected, unintuitively named man pages.
systemd: good idea, horrible implementation.
So upstart has some things that need to be fixed (mostly the clean shutdown thing)...
Systemd is a monster that gets to infect more of you packages over time, plus you get the benefit of binary log files!
I hope they choose upstart and just fix it up a bit.
OpenRC has been proposed by some too, which seems like a nice sysvinit replacement, but event driven startup and shutdown of services (think laptops and hotswap stuff) is more important than just a fast startup time.
Upstars solves some problems with sysv, but includes a whole array of new ones. Systemd solves almost all problems with few new ones, except for all the parts that is not implemented yet. Systemd is a mess for novices to use and understand, the helper tools are not as good as they should be.
mostly okay for some stuff, and utter **** for anything else.
So mostly okay for some stuff, and four stars out of five for anything else? Pretty good, pretty good.
Debian has a habit of not using things until they work. I expect they would fix most of the issues or they wouldn't ship it.
This is very true.
Like much in the linux world these days, systemd was rushed into production before it was half completed by too many distros.
At least you have to give Debian the credit for waiting until most of it is working, and all the necessary patches have been identified.
(The less charitable way of viewing it is that Debian sat back and let others do the heavy lifting).
Probably the worst case would be for them to choose upstart when the rest of the industry decides on systemd. That kind of divergence
makes for much more work patching everything that needs to be patched.
Sig Battery depleted. Reverting to safe mode.
I hope for systemd; I know it from Fedora. And in my opinion upstart is some kind of mess; it's a mixture of bash script and their own added syntax. It kind of feels like Microsoft's extensions for C++. I'm also a fan of declarative configuration like systemd is. After 5 minutes reading the manual of systemd I could write my own service for pdnsd.
[Unit]
Description=PDNSD
ConditionPathIsMountPoint=/mnt/read
After=NetworkManager.service
[Service] /var/run/pdnsd.pid
Type=forking
ExecStart=/usr/local/sbin/pdnsd --daemon -p
PIDFile=/var/run/pdnsd.pid
[Install]
WantedBy=multi-user.target
# systemctl status pdnsd /var/run/pdnsd.pid (code=exited, status=0/SUCCESS) /usr/local/sbin/pdnsd --daemon -p /var/run/pdnsd.pid
pdnsd.service - PDNSD
Loaded: loaded (/usr/lib/systemd/user/pdnsd.service)
Active: active (running) since Mon 2013-10-28 18:46:23 CET; 1h 14min ago
Process: 1585 ExecStart=/usr/local/sbin/pdnsd --daemon -p
Main PID: 1587 (pdnsd)
CGroup: name=systemd:/system/pdnsd.service
1587
Oct 28 18:46:23 vostrotitan.localdomain systemd[1]: Starting PDNSD...
Oct 28 18:46:23 vostrotitan.localdomain pdnsd[1587]: pdnsd-1.2.9a-par starting.
Oct 28 18:46:23 vostrotitan.localdomain systemd[1]: Started PDNSD.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
No Solaris SMF was a good idea, systemd is what you get when someone looks at that idea and says "you know what, I can fuck that up."
"I use a Mac because I'm just better than you are."
To shutdown: yank the power cable.
To reboot: yank the power cable, then plug it back in again. Then depress power button if necessary.
Accompany either process by shouting the magic words "fuck it, it'll probably be fine".
You need to remember that most of the time Debian is not about developing new stuff, it's primarily about PACKAGING and DISTRIBUTING existing stuff.
From "package a bunch of software into an usable system" standpoint it is a smart decision to wait until the dust settles and things are tried and proven. Especially if you are producing system as stable as Debian Stable.
--Coder
systemd service files are quite straightforward---I'm not sure what kind of monumental effort you are referring to when creating service files. For a simple service, starting/stopping/restarting the service is handled automatically, leaving a very minimal service file.
For example:
[Unit]
Description=AutonNav
[Service]
ExecStart=/usr/sbin/autonnav
Type=forking
[Install]
WantedBy=multi-user.target
After having repeatedly run into the limitations of SysV init, I'm all for replacing it with something smarter, but I'm torn between these two.
I've used Upstart on Ubuntu, both as an admin and as a developer. I like that the commands and configuration files are clean and pretty easy to understand. A few things bother me, though:
I haven't used Systemd at all, but the common points that come up again and again in every writeup I encounter have me forming me some opinions already. I really like the idea of the load-as-needed dependency model. A few things have me quite worried about the implementation, though:
So one prominent example is a push to discard syslog, but at the same time rejecting any suggestion that perhaps it might be nice if the same plain text that journalctl can produce be produced as a matter of course without syslog assistance.
Yes, journalctl has more readily accessible nice filters and faster performance. The issue is that the vast majority of people didn't ever need them and made due with grep and friends. Yes it's not good stuff to build a high-end solution out of, but by the same token journalctl power is more complicated to use.
Getting early boot messages would have been a straightforward thing to do in syslog land, it was just that no one bothered. It was a good thing to add, but generally either things work fine and you don't really care much about the early boot logs, or it fails to get root fs going in which case the logs from that time won't make it to the root fs hosted journal anyway.
I don't like the linux distros of today because they are largely reimplementing much of what people ridiculed microsoft for in the 90s (binary configuration, binary logs, more complex messaging model). While it is true that generally the details of the implementation are defensibly better than microsoft did, the differences are largely academic to the vast majority of system administrators. Vast majority sees opaque binary blob that is useless without a very close match in distribution to provide tools to analyze. Even when things are humming along fine, things like dbus provide capability in a nearly impossible to explore manner. Even with all this complexity, my linux server experience is no more useful than it was 10 years ago from a managability standpoint, but I've had to jump through hoops to try to track the complexity as it emerged bit by bit without a lot of nice capability to come along for the ride.
XML is like violence. If it doesn't solve the problem, use more.