Debian To Replace SysVinit, Switch To Systemd Or Upstart 362
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."
Re:Ugh (Score:5, Informative)
Re:Uh... (Score:5, Informative)
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).
Re: Canonical might suck... (Score:2, Informative)
No! Sadly this is the case. I had a script that deletes old entries in /run. By accident I removed /run/systemd and figured out that you can not shutdown or reboot anymore. Only hardreset or poweroff lets you bypass it. This is not and was never necessary with sysvinit.
Hoping for systemd (Score:5, Informative)
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.
Lennart Poettering explains why Upstartd is bad (Score:2, Informative)
https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf
Re:I've got OpenRC installed... (Score:3, Informative)
Simple and effective - and no symlinks all over the place like in SysV. It automagically orders services. If foo needs bar bar is started before foo.
And I see now that it is what OpenRC is... or atleast was.
Re:Ugh (Score:4, Informative)
What I would consider the old system would be something like SlackWare(RC scripts) where the system might have 8 or 9 different shell scripts called during the boot process, but it's essentially one giant autoexec.bat. Simple to make modifications to the boot process, but installing new services or upgrading the system may require manual merges and break your installation.
The current system is more like RedHat/SuSE/debian(Tradtitional init), where there are tons of scripts that call other scripts and it gets pretty complicated, but for the most part everything is a script and can be easily traced. This is more difficult for the inexperienced to modify, but is reasonable for those familiar with scripting and is great for adding new services and upgrading the OS. Basically the scope of a change is smaller, so less stuff breaks.
The new system is something like Fedora/Ubuntu(Systemd/Upstart). There are config files for everything from services, to devices, to sockets that are parsed by a binary that isn't very open to inspection. This leads to a very fast boot up and has neat features like the ability to view the logs of a service with the same command used to start it, but is also like sticking your dick in a box of razers, because when something goes wrong you can't just pull out vi and look at the logic being used to boot the machine. It also leads to somewhat unsettling things like a merged
To be fair this might be somewhat unfair to Ubuntu, because I haven't invested much time into Upstart. If it was something worth looking at I'm sure the Fedora/SUSE devs would have dropped systemd for it though.
What would be really nice is if Debian built a version of systemd that didn't have a big binary core, or at least split the thing into several different services. I like the speed and slickness of systemd, but if anything goes wrong with a system using it, I will have no idea how to fix the thing -- and that's after using systemd on my primary laptop/server for over a year.
Debian did well to wait (Score:5, Informative)
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
Re:Uh... (Score:4, Informative)
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
Re:"the Canonical bias present on the committee" (Score:4, Informative)
What do you mean by Iceweasel? That name change came because Mozilla actively asked Debian to do it, so they did.
Re:Uh... (Score:2, Informative)
Its "obtuse", but your point is taken
Actually, it is "abstruse".
abstruse
adj. Difficult to understand; esoteric; recondite.
Re:Upstart (Score:2, Informative)
OpenRC can start or stop services based on events...