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."
Yeah, SysVinit is not only fine but preferable. It's simple and effective. I see no reason to change.
I really wish you'd get off the fence and pick a position on the issue.
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.
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.
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