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."
Canonical might suck... (Score:4, Interesting)
But that doesn't mean that Upstart does.
Re:Canonical might suck... (Score:3, Interesting)
Yea who doesn't want their DB servers kill -9'd if they take too long to shutdown. Hooray upstart.
Re:Canonical might suck... (Score:2, Interesting)
IMHO, it does (suck) when compared to Systemd.
I've also found moving from System5 based init's easier with Systemd
Re:Ugh (Score:5, Interesting)
Yeah, SysVinit is not only fine but preferable. It's simple and effective. I see no reason to change.
Re:Canonical might suck... (Score:3, Interesting)
Should go with launchd.
How about OpenRC? (Score:4, Interesting)
Why not keep sysvinit and switch to OpenRC for managing the init scripts?
Re:Canonical might suck... (Score:4, Interesting)
Well my first thought on this was.....its a smart move for desktops, but I intend to continue using sysvinit on servers for a long long time to come.
Really? (Score:4, Interesting)
This is your way of stating your opinion? Looks, like your parents forgot to teach you something particular important to be considered an adult and able to participate in a discussion. You could say that you disagree with Canonicals decision towards Wayland/Weston. You could say that the way they handled the issue and announced Mir sucks and was not a cooperative mode. In addition they made some bad blood. And that all would sound like someone really discussing the issue, but really you just sound like someone either too young to remember the vi vs. emacs wars or like someone exhumed from that day, just to behave like a troll.
BTW: Get a life, normally that reduced these urges to hate someone just because you find his or her decision questionable.
systemd - bad & getting worse (Score:3, Interesting)
I used to not only use RedHat, but contributed fixes. Ubuntu is not, in many respects, my ideal, but systemd is enough reason all by itself for me to use Ubuntu.
Go home Debian, you're obviously drunk (Score:4, Interesting)
SysV init scripts just work. They are simple to create and easy to maintain. Debugging is a cinch when things go wrong -- and a lot of packages DO NOT get upstart init, nor SysV init correct. Upstart is only easier in theory. In practice it's made a complete mess of things and I have several Ubuntu systems to prove it.
I've got OpenRC installed... (Score:5, Interesting)
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.
Re:Really? (Score:4, Interesting)
It's far too easy to shoot yourself in the foot with upstart. It is much more complicated. In it's efforts to solve a non-problem (namely making a machine boot faster) it tries to do things in parallel and creates a web of dependencies that can render your system unbootable.
It adds extra complexity for dubious gain.
It's the perfect example of why we shouldn't necessarily accept the advice of "helpful types" that think that things should be done the way that Microsoft does it or the way Apple does it.
Re:Go home Debian, you're obviously drunk (Score:5, Interesting)
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.
Finally! (Score:5, Interesting)
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...
Re:Uh... (Score:5, Interesting)
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.
None too soon! (Score:4, Interesting)
Default versus monopoly - FREEdom software (Score:2, Interesting)
Debian should stay true to its core principles. The user should be able - by installing a package - to choose the init system she wants.
There is no one true mail server on Debian. You can choose to run zsh as a shell instead of bash. There should never be only one supported init system.
Distributions don't choose, users do. Oh and technical committees are there to find solutions to make that work, not to complain about how difficult that is.
Re:Go home Debian, you're obviously drunk (Score:5, Interesting)
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.
I'm Torn (Score:5, Interesting)
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:
Re:Startup times are important (Score:3, Interesting)
Yes, complexity is evil, the problem is that sysv is complex (read: bash is complex) and running bash's init code hundreds (thousands?) of times and seeking all over disk eats lots of time.
The solution therefore, is not to introduce something even uglier and more complex like Upstart or systemd, which STILL runs bash init code hundreds of times, and seeks all over disk, but now also adds megabytes of source code that one either has to audit or put blind faith in, even though both systems are empirically unreliable.
The solution (which I use) is to have a program which generates C code, which does all of what init does in a few kb of source and a few more kb of binary, and recompile that each time you want to change what runs at startup. The solution to seeking all over disk (which is by far the bigger time sink), is to put everything that runs at startup in an initramfs, so it is read sequentially from disk at boot (which I do), or to add precaching to the filesystem, so you can mark files needed at boot, and have them stored sequentially on disk, and read by the kernel into iocache at startup (which I have not done).
Another problem is that lots of programs create files on filesystem at startup, such as pid files, log files, cache files, and distros put those directories where they live in the on-disk filesystem, even though they are small, and ephemeral, there is no point in keeping them after a reboot, and logs should be sent to another host, not stored on the local machine.
I've basically solved all these problems, but not the iocache priming problem, as I use a tmpfs root and run my entire OS off ram*. There's not much point sharing my source code for my init generator, as it's too simple and my-use specific to be generally useful, and the idea behind it is what is worth sharing, which I have now done in this posting.
* there's plenty of other good reasons to do this.
Re:Canonical might suck... (Score:4, Interesting)
Re:Hoping for systemd (Score:4, Interesting)
And then:
# start minecraft
I cannot see a single line which requires documentation in order to understand it.