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: (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: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.
Re: using your own startup? good luck (Score:3)
Good luck w/that.
I hope you don't expect to update any SW on your system for a while.
opensuse has gone out of their way to make their systems NOT be systemV compat... including moving to a requirement for booting from a ramdisk image (because systemd doesn't handle PATH, it uses fixed paths for it's binaries), integrating the power, device, udev and logging subsystems into systemd, with logging going to a binary MS-like format that is, by default, not saved.
Also put all the var/run files on ram disk, so p
Re: (Score:2)
What's wrong with
kill timeout 64800
Re: (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: (Score:3, Interesting)
Should go with launchd.
Re: (Score:2)
Upstart sucks.
Every time I've tried to make new software be controlled by it, I've wound up writing horrendous kludges or (where possible) rewriting the source code to make it more upstart-friendly.
Upstart is to init systems what Unity is to desktops - mostly okay for some stuff, and utter **** for anything else.
Re:Canonical might suck... (Score:5, Funny)
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.
Re:Canonical might suck... (Score:4, Insightful)
It's the fact that Upstart sucks which means that Upstart sucks.
At least from an embedded perspective (which is the majority of linux systems) the system should start only that which is necessary rather than everything that is possible. It also suffers from the classic stampede mistake when it becomes possible to start a whole load of new services after a shared dependency is started.
Re:Canonical might suck... (Score:5, Insightful)
Re:Canonical might suck... (Score:5, Insightful)
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.
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: (Score:3)
Well, that and Lennart Poettering tends to not constructively respond to requests by users. He's done some very sophisticated work, but in many ways fails to understand the reality of most sysadmins. He wants all sysadmins to be able to handle the new capabilities rather than coddle them with plaintext log formats, even though over 95% of the audience doesn't *need* the stuff that is hard to do in a plaintext log format.
MS has done the same thing, system registry, event log, etc all act very similarly to
Re:Canonical might suck... (Score:5, Insightful)
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.
Re: (Score:3)
You can still disable binary logging, as I will continue to do and as long as they don't remove this. Everyone can be somewhat more happy and get best of both including syslog redirection still.
Re: (Score:3)
The problem is that some of the difficulties are by design. journalctl and systemctl are actually pretty straightforward to use. However, when things go off the rails, it's much harder to cope with than a system that retains plain text logs at the core. The argument that journalctl can give you plain text rings hollow when the tool is hard to get to (system had catastrophic failure and you are on the wrong end of a crappy connection but have a random system nearby that can peruse data. Lennart would c
Re:Canonical might suck... (Score:4, Insightful)
Why not just make the journal in a standardized format, that can be read by any other system? If I need to look inside a .zip or .tar.gz file, I don't need tools on a specific computer to do that; I can copy those files to any computer and look at them with zip/unzip or tar/gzip. Why should it be any different with systemd logfiles? You shouldn't need to use the computer that generated those files to read the files, just the same tool on another computer. If that's a problem, then there's a serious failure in implementation.
Re: (Score:3)
But surely you don't reboot Linux so often that it is a major concern whether it takes 1 minutes or 10?
On servers, no. Laptops, however, are a different animal. Yes, you can avoid some reboots just by using the normal suspend and hibernate modes (IF hibernate works on your laptop), but not all, particularly when there's a kernel update. People generally like to have laptops that can start up and shutdown quickly, particularly when Windows can do it so fast these days.
Re: (Score:2)
Re: (Score:2)
Yeah, well, don't do that. There is a reason its all owned by root.
Re: (Score:2)
I am root you insensitive clod!!!
No caps seriously /.
Re: (Score:2, Funny)
with my own owned stuff
You own your own dick too, but there is no point in complaining you can't get it up once you cut it off.
Re: (Score:2)
Go ahead and delete system32 while you're at it. It's your computer - pay no attention to those naysayers who try to talk you down from deleting it.
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.
Re:Canonical might suck... (Score:4, Interesting)
Ugh (Score:5, Insightful)
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
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: (Score:3, Funny)
I'm with this too. Fuck Canonical. They have become a real pain in the ass, and worst of all, they're a pack of fucking retarded assholes. I can't say it enough. Fuck Canonical. Fuck Canonical. Fuck Canonical.
Debian is one of the best distros out there, let's not allow the fuckwaddery that is Canonical and their arrogance and intense stupidity ruin it. The current init system works just fine.
Oh, and in case you didn't get it. Fuck Canonical. Fuck Canonical. Fuck Canonical.
Re:Ugh (Score:5, Funny)
I really wish you'd get off the fence and pick a position on the issue.
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.
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.
Startup times are important (Score:4, Insightful)
I agree that complexity is evil. I have no experience with systemd nor with upstart, so I cannot comment on them. However, dependency graph and parallel execution should not be THAT difficult or complex
--Coder
Re: (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 unr
Re: (Score:3)
Re: (Score:3)
While don't dispute that many machines do have problems, since Linux can give you a horribly different experience depending not only on the distro you've chosen but also the hardware you're using, my laptop works almost perfectly in recovering from sleep, in fact I do this all the time, many times a day. I'm using a Dell Latitude E6400 with Mint KDE.
In my experience and observation, the business laptops tend to be MUCH better supported in Linux than the consumer ones. So if you're not already using one, g
Re: (Score:2)
It *shouldn't* matter how long it takes your server to boot, but it really could be critical in the event of an outage. In any case systemD solves more problems than optimising boot times.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
fuck pico, nano is where it's at!
Re: (Score:2)
...except that upstart doesn't meet that description.
It's more complex, therefore more subtle, therefore less repeatable and more difficult to debug. If I had a large number of machines of ANY sort, upstart is the LAST thing I would want to have to deal with.
Upstart is barely tolerable for desktop purposes.
You throw around "million" like its going to impress anyone. Many of the people around here already manage a volume of machines large enough to boggle the average human numeracy.
Re: (Score:3)
Re:Ugh (Score:5, Informative)
Slackware systemd is better (Score:2)
At a former university the desktops used Slackware with initscripts all the way up until 2011. These desktops were beefy machines with decent chunks of RAM and SATA disks but would take minutes to finish booting. The administrators there switched the start-up scripts to systemd across a holiday and things became dramatically better - no boot took more than 30 seconds and most disk based boots were sub 15 seconds making the old system look laughable.
I'm glad that Slackware gave the admins the choice because
Re: (Score:2)
I havent noticed any such slowness with slackware startup myself, so I suspect a misconfiguration, but nonetheless, even if that were the cost, having sensible human-readable startup scripts is well worth a couple extra minutes boot time to me anyway. Seriously, how often do you reboot a *nix box? No one really cares how long it takes to do that one-in-a-blue-moon reboot.
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: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.
Re: (Score:2)
...abstruse and incomprehensible to anybody outside their little circle.
Its "obtuse", but your point is taken. But let's be honest, many, if not every, circle of technical wizards in charge of a popular project gets infected with elitism to some degree. I will say however, and without really understanding the exact technical reasons canonical seems to be taking the technical "high road" and laughing some of their userbase writhes in pain on the ground behind them.
Re:Uh... (Score:5, Funny)
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."
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: (Score:2)
Please tell me how to reboot or shutdown a systemd based distro if the /run/systemd directory got deleted by accident.
Wait, seriously? You don't know how to kill processes and umount filesystems? YMBNH
Re: (Score:3)
Killing process isn't the point. Just try it for your own.
I have. If you can get all the appropriate daemons terminated and your filesystems unmounted or read-only, you're done. What were you hoping to accomplish, having the machine turn itself off? Who cares?
Re: Uh... (Score:4, Funny)
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".
Re: (Score:3)
Its daemon management, It by its nature touches a lot of stuff to do its job well. Now the relivant question is, could it do everything it needs to do in a cleaner fashion with well established interfaces allowing other programs to do the same thing, while also limiting systemd to just do a subset of it. Leinart seems think that's a silly goal, to have a daemon manager that isn't as good as it could be.
Re: (Score:2)
There are reasons to do more than that, but they all add complexity. Some developers are more interested in new features than in reducing complexity.
Ie, if you want graphical control over "services" then the current method of dropping any old random script in a directory is not too helpful. Also all the SysV style scripts are assumed to run sequentially and are ordered via priority in the file name, which makes it more difficult to start a lot of things in parallel (not a big deal for a server but some pe
Re:Ugh (Score:5, Insightful)
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
Half of that is because either SystemD or upstart is really only about half implemented, and the half that is implemented is often trying to replicate sysv just to keep the conversion and learning task to something approaching manageable. Its kind of a mess right now in many distros.
As more of the system targets are properly implemented, and users start to let go of the concept of run levels, and get used to dealing with target files and the concept of units, it will be every bit as tailor-able as run levels were, and a whole lot faster.
I didn't find run levels and rc.d all that intuitive at first (many long years ago) and the scripts were more complex.
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.
Why keep making simple things complicated? (Score:5, Insightful)
Re: (Score:3)
Because it help useless techies employed. You really can't justifiy selling RHCE training and exams without this crap.
Re: (Score:2)
It also keeps OSS companies relevant.
How about OpenRC? (Score:4, Interesting)
Why not keep sysvinit and switch to OpenRC for managing the init scripts?
sysvinit is dead; long live sysvinit!!! (Score:3, Insightful)
Tell me I'm not the only one still clinging to sysvinit?
The new "replacements" (alternatives) are ghey++ and will no doubt be replaced in due time.
I dno't want to hear about a few seconds faster boot time. I want my *nix startup to be configurable, scripted, and simple. sysvinit takes the cake;.It's documented, and sysvinit is so simple it doesn't really require documentation, anyway.
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: (Score:2)
Not that many people will agree with this assessment.
No, I've been thinking that too. The more they try to make Linux like Windows, the less reason there is not to consider other operating systems.
It's certainly true that making startup work reliably with init scripts can be hard: service foo has to start after service bar, which can only start after the network is up, or whatever. But none of the alternatives seem appealing yet.
Re: (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: (Score:2)
Opensuse dropped sysvinit when the current level came out several months ago. Before that they had defaulted to systemd but allowed sysvinit.
My considered opinion of systemd? I hate it. I don't have a server farm, I have a couple of desktop machines with Samba and nfs capability and sysvinit was ideal.
Re: (Score:3)
I still use SysV because solutions are portable. I work on every flavour of UNIX and some I shouldn't even be able to run anyway. I don't want to write solutions for multiple inits.
SysV for as long as they'll let me. My systems will stay up longer, take less work to maintain and configurations be clearly apparent to actual sysadmins.
Just my two cents.
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.
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.
Re: (Score:2)
Anyone trying to tell you that Upstart is easier is simply lying to you.
Upstart is more complex by design.
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.
Where to send hatemail? (Score:2)
This sounds like a really awful idea, based on what I've read here. I like how Debian's init works now, its fine, there's nothing wrong with and it's simple.
Where the heck do I send hatemail to perhaps encourage them not to do this?
"the Canonical bias present on the committee" (Score:4, Insightful)
Re: (Score:2)
It's Debian. You know, the distro that prides itself and defines itself on not including any non-open source code in it's repositories. Debian is a political statement.
Re: (Score:2)
For a specific example:
IceWeasel.
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.
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: (Score:2)
Massive amounts of boilerplate code?
I guess we've been using different SVR4 variants. I just use a case statement to test the first argument...
My beef with upstart et al is that they disable, instead of deprecating, old init. That means now I have to maintain at least three sets of scripts instead of two (sysv, bsd) for software distribution.
And what the hell was wrong with inittab? Let's see, it's succinct, works, and is fully debugged.
Re: (Score:2)
I suppose that's what I meant. The scripts that ship with debian by default are far more difficult to comprehend than upstart scripts. I suppose if all you do is check the first argument and then start the executable then sysvinit is just as easy. The problem is that usually the scripts are supposed to do way more than that, things that upstart takes care of.
Upstart (Score:4, Insightful)
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.
Re: (Score:2)
I honestly wonder what the systemd developers were thinking when they turned it into a feature-creep laden mountain of mostly annoying features which slowly takes over the system from you. The way it seems to force itself into other things in the system (e.g. by way of systemd-specific modifications in daemons and such) just should have set off a lot of software engineering alarm bells. Why didn't that happen?
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.
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.
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.
Lennart Poettering explains why Upstartd is bad (Score:2, Informative)
https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf
Re:Lennart Poettering explains why Upstartd is bad (Score:4, Insightful)
Wow, with such a superior, arrogant and manipulative attitude, I think it is time for Debian to write their own, or continue with what they have. I would have nothing to do with someone who has so little respect for anyone else's efforts, using FUD against other projects, and who is so obviously trying to lure people into his self-serving spider-web trap. Perhaps his vision is that systemd will be the one process to rule them all, my precioussssss... and then finally Linux will be all his. Run away!!!
OpenRC (Score:2)
Because:
1. What sane organization wants to follow in Canonical's footsteps?
2. Who, besides an utter fool, thinks systemd is a good idea?
Conflict of Interest (Score:2)
FTS: 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."
So what are the chances of getting the Canonical-associated board members to recuse themselves from the vote, given the obvious conflict of interest there?
systemd only supports Linux (Score:3)
And that is a good thing for Linux because it can use a lot of good technology from the kernel. The major issue is that systemd requires cgroups and that means no support for kFreeBSD. Even if the ex-Canonical people recused themselves, systemd was always going to have an uphill battle.
There is a Debian derivative that has decided to use systemd, but it's -- the still incubating -- Tanglu.
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:
systemd tries to do too much (Score:3)
systemd falls into the same trap as "desktop environments". It starts with appealing goals (basically, make startup a graph that is traversed parallel-breadthfirst), but it winds up sucking. Consider what happens when systemd dies. This happened to me recently (fedora19, upon resume) - there's not much you can do except reboot. Yes, this could have happened with sysvinit, but who among us ever had a crash of init? I certainly haven't, and I'm a certified greybeard.
AFAIKT, the problem is that it's trying to borg a whole bunch of subsystems that do a great job by themselves. For instance, systemd tries to replace syslog for the most part. It's easy to see why it would want to do this, since daemon/server IO is a useful part of managment. But trying to do so, the system becomes more fragile and *narrower* in its applicability - more specific to how one guy (Lennart) thinks every system should behave.
I suspect what will happen is that systemd will get shaved down a bit with some of the excess functionality removed, and in the process will become reasonably robust (ie, NEVER crash).
code size (Score:3)
Upstart (1.5): 285 files, ~185k lines, ~97k C
Debian: sysvinit + 120 files, 5.8k lines
systemd (v44+): dbus + glib + 900 files, 224k lines, 125k C
sysvinit: 560kB, 75 files, ~15k lines
Debian startup is smallest, it's only shell with sysvinit (C) as dependency
Upstart is about 10 times bigger in terms of lines of code/text. Most of the extra complexity size comes from C.
systemd is about 10 times bigger, like upstart. But with the mandatory deps it blows up to about one hundred times the code footprint! Most of the extra code is in mandatory dependencies, but the systemd core is also bigger than anything else.
http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems
Are any of the replacement deterministic? (Score:3)
I don't care what they replace it with, so long as there's a flag/switch/option somewhere to make the boot deterministic and identical across systems and across boots.
We run ~5000 diskless clients using Debian, booting via PXE/TFTP and mounting all filesystems via NFS.
With Debian 5, everything ran perfectly. With Debian 7, the boot is now very racy and too many things depend on the speed of the network (some services start before their dependencies are ready). We actually had to turn on verbose boot messages in order to slow things down enough for everything to boot correctly. We're testing the "don't run in parallel" flag now to see if that fixes things.
It's virtually impossible to debug a concurrent/parallel boot system, as every boot is just slightly different from the last. With the original sysvinit system, where things ran in series, one after another, it was very easy to find problems and fix things.
We don't care if the computer takes an extra 15-30 seconds to boot; we boot everything in the morning via WoL before classes start, and they are rarely booted during the day. What we do care about is being able to debug problems and make things work the same, time after time after time.
Upstart doesn't sound like it helps much in this area. Don't know about SystemD.
WWBD? (Score:2)
Re: (Score:2)
Yeah, I never understood the whole idea of putting GNU on top of FBSD. It would have been useful had Debian ported things like Apt Get to FBSD, but here, they want the whole userland. Is the FBSD kernel that much better than Linux? Debian might have had a point had they done something like Debian GNU/Minix, where they put GNU userland on top of the Minix microkernel. A case where the userland doesn't exist, like in Linux. An even better project for Debian could have been a non-GNU userland for Linux.
Re: (Score:3)
I've heard tempting-sounding things about Debian kFreeBSD, actually - aside from anything else, BSD has a port of ZFS. So if you want something with a familiar userland (GNU utilies, Debian package management, loads of packages available) it does look quite appealing. I'm not sure how common it is to use ZFS under FreeBSD so far, though.
Also, there are Solaris distros out there, which is potentially another way to get the same effect. Nexenta started as one, though I remember them switching more to focus
Re: (Score:2)
Re: (Score:3)
There is an old saying, "Standard is better then the best solution", but programmers and engineers have a natural desire to build better solutions, even when it is not such a good idea.
That is not to say everything must remain static, and it is fair to say there are some functional