> Why don't you do that [i.e. vote against systemd]
yourselves?
>
> We are excluded from voting on the issue: only few of us
> have the time and patience to interact with Debian on a
> voluntary basis.
.....
In that case, you don't have the time and patience to operate and maintain a worthwhile and ongoing Debian fork.
In that case, there is no substance to the "question" you're raising, because you wouldn't actually do what you're calling for.
In that case, you're just a handful of guys (or maybe even just one guy) who spent $10 on a domain name... to get more attention for your Slashdot/Reddit/HN post than it otherwise would have had if posted straight to Slashdot/Reddit/HN directly.
Only a Debian Developer can vote on a General Resolution. The process for becoming a DD can take, and I am not joking, years. See the actual stats here: https://nm.debian.org/public/stats/
The process is oriented towards supporting the development and maintenance of packages in Debian, which is probably as it should be, but it means that the viewpoints of people who actually use Debian -- and the vast majority of these are systems administrators with hundreds to tens of thousands of machines in their datacenters -- are not part of the organization.
Many decisions are based on the results of people installing the popcon package -- it's a popularity contest that sends the list of installed packages back to debian.org, and for that reason it systematically overcounts individual desktops and systematically undercounts servers in places which have even the vaguest notion of a security policy.
I came here to say exactly that. "We don't have time to work with the Debian folks on a solution, but have time to create our own distro." Right. Then again, they should go for it. If nobody but them uses it, that's that. If it gains traction, cool.
On another point: why the hell would you have a choice in init systems? As a user of the OS, I care that the proceses start, stop, and keep running. I don't care how. A purist in me might care, but I am not going to futz with installing different init systems for no good reason.
Nobody said you had to futz with it. Ideally packages would ship with the correct init scripts and things would work exactly as you expect them to, or as they did. Unlike with systemd.
Why the hell would you have a choice in kernels?
Why the hell would you have a choice in filesystems?
Why the hell would you have a choice in sound systems?
Why the hell would you have a choice in desktop environments?
To clarify: why would you want a choice in init systems in a single distro? To me, a distro is a package manager+packages and an init system. You add a different init system, you have a different distro. Everything else is modular, but the init system is something that is at the very core of the OS. This is why most distros support multiple kernels, file systems, etc. but only one init system.
> Debian lets choose between the Linux, FreeBSD, and Hurd kernels, but choosing an init system is too much?
Unless you actually want to use one of these kernels that are not Linux. Hurd has nerver made it into a stable release and kFreeBSD is on the verge of being dropped as well.
There is only so much manpower and supporting every possible init system on every possible architecture on every possible kernel is getting out of hand.
There needs to be a distinction between Linux distros for us, and Linux distros for everyone else.
For us, we care about all that stuff, because we are engrossed in it daily. For everyone else, they will never touch or understand and / or should never need to understand what a kernel, filesystem, sound system, or desktop environment is. To them, the computer is a tool, not an environment, and to use it is to press buttons to get some tangible result you want from it, and the buttons you have are not buttons you are going to know how to change.
So I want a choice in kernel, filesystem, etc because I care about the semantics, performance, ethics, and implementation of these things because I interact with, code for, and code against, them on a near daily basis. Everyone else does not know they exist, and thus don't care, so choice is irrelevant to them, in the same way the existence of Linux as an OS "choice" does not matter to them - if it is not on the notebook on the shelf at Best Buy, it might as well not exist.
Thing is, Debian is already effectively (since Ubuntu) a Linux distro that's supposed to be for us. People who want a nice desktop experience go with Ubuntu, people who want a server reach for Debian.
If the higher ups at Debian really think they're going to be a player in desktop and are making decisions along those lines, then they must be seriously oblivious to the niche that Debian has actually settled into post-Ubuntu.
Your distinction is both wrong and too simplistic. Debian has a perfectly respectable Desktop, and Ubuntu has more than a good server product.
Choosing between them depends more on technical and project requirements.
Whilst I am not a fan of SystemD, it is important to remember that it came from RedHat.. you know, the people famous for servers.
SystemD will be a good init for Server, as it will be for Desktop. i am pretty critical of SystemD, but something is better than Sysvinit. I'd have favoured Upstart, but that doesn't matter... SystemD won, people need to deal with it. This is a good evolution for Linux.
There might or might not have to be a division between distros - personally, I think you can serve both demographics by having choice and good defaults - but I don't think Debian has ever been the distro for the "inner workings don't matter" crowd. That's why Ubuntu was made.
To them, the computer is a tool, not an environment, and to use it is to press buttons to get some tangible result you want from it, and the buttons you have are not buttons you are going to know how to change.
Your general point is correct, but the analogy you're using is incorrect.
It's not tool/environment, but rather, it's tool/appliance.
The fundamental cultural shift going on between many anti-systemd and pro-systemd people is that the former want the computer to be a tool, something that with proper discipline and skill can yield great things, whereas the latter want it to be an appliance - something that you fire and forget, and is meant to be inflexible and that "just works".
The problems, as always, are that tools have learning curves and often need to be composed into more complex configurations to yield more powerful results. Whereas appliances, although they "just work", they work only for predictable and formulaic configurations that the appliance explicitly expects, and proceed to break down and reveal their opaque innards when used for more esoteric or unusual situations.
In summary, the anti-systemd side wants to do things with their computer, and the pro-systemd side wants their computer to do things for them.
This is why there will never be a consensus. It's also why systemd opponents will often resort to stupidity like defending the messy hairball of SysV initscripts, while proponents will just casually look at unit file configuration being outwardly simpler and not think of the bigger picture.
Because when you're a sysadmin, you often have to write init scripts for the software you have to run.
Typically, you run servers for a company, the developers wrote a web application and the whole point of the server is to serve that app. You need init scripts to start, stop monitor this app. The choice of init system makes a big difference in your daily life.
I'm a devop, not a system administrator. I setup and administered a number of single machine web services for my customers along the years, almost all of them with Debian plus some Ubuntus recently. Database, application server, web server. Nothing fancy. I also use Ubuntu as my primary desktop (some sort of gnome fallback DE) after I removed a lot of cruft if comes with by default.
From my experience what I need on a desktop is very different from what I need on a server. On a server I don't care about displays, keyboards, backlighting, sound, USB disks, mics, scanners etc. On my desktop they are very important. There are a number of companies offering Linux VPSes with 512 MB RAM and they can be good to host a low traffic web service. Good luck running a modern Linux DE on a 512 MB machine. Not impossibile but not very productive.
So I can imagine having very different init systems for desktops and servers if this means that the server won't be encumbered by a number subsystems which are of no use to it. Furthermore binaries instead of scripts and opaque log files leave a bad taste in my mouth. They make me figure a future with a Windows like event viewer to browse the log files, over a terminal based ssh connection. I'm quite concerned about it. It will waive one of the biggest advantages of a Linux server over a Windows one.
A fork, or an alternative init system, could be a good solution. We should run this experiment, pick what we like and don't harass the people on the other side. We will see the results after some years. The satisfaction of the admins will decree the winner.
systemd has a number of features which are of interest to server operators, especially those who use containers, which may well be many of us before long.
Running systemd as pid 1 does not imply running a desktop environment.
I have plenty of VPS customers running systemd as pid 1 in 512MiB RAM.
Running systemd as pid 1 doesn't imply having every single binary and subsystem of systemd running.
I would encourage you to try it before deciding it's something you won't find useful.
Avoiding it looks like it's going to be significant effort and you'd want to know for sure that you're justified in that before embarking on that course of action.
Yep, this is true. The only thing I concluded from this page is "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork".
Actually, I find it's funny how anti-systemd people nowadays claim that "systemd is a init for desktop systems" since Gnome adopt something unrelated to the _init_ part of systemd that is the systemd-logind (that actually is a substitute of ConsoleKit that was deprecated god knows how many years ago). systemd has lots of features that makes sense on servers too. You may or may not need these features on your server, but systemd (as a init system) is still a better init system than sysvinit.
Actually, systemd is pretty awesome for servers. I wrote a simple program that outputs to stdout and ran it under systemd.
* it automatically cares about starting it
* it automatically puts the programs stdout into the journal (from which I can filter the output of my specific program without having to syslog() everything)
* it allows me to run the program as user with one line in the INI unit file
* it allows to make the users home directory read-only (or even inaccessible), so in case someone takes over, there is only so much they can break
* it can create a private /tmp for my program
Actually, for desktops I don't care but for servers systemd is pretty awesome.
You hit on some of the points that won me over when I first started using systemd. Writing services is easy and logging their output is a breeze. Not having to fret with supervisor processes or daemonizing code shifts some of the complexity out of the application and into the init process[1] where I'd argue process management ought to live.
Given that targeting sysvinit for all the various sysvinit-compatible systems out there can be an exercise in frustration (OpenRC, Debian, the *BSDs, all of whom have subtly different flavors for starting and stopping processes) better left to individual maintainers, it's nice that I can write a unit file and pretty much have it work on any system that's running systemd.
[1] I'm aware that some people might argue additional complexity doesn't belong in an init. That's fine. You're probably right.
And if there is a situation where your program is acting wonky, what non-systemd command can you use from the shell prompt to debug and reproduce exactly what systemd is doing?
> Yep, this is true. The only thing I concluded from this page is "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork".
Yet the oddly amusing part is how systemd isn't difficult to learn. The only valid complaint against systemd IMO is its departure from Unix philosophy, but for some parts of the nix ecosystem, I can't help but think that boat sailed long ago.
I was hugely resistant to systemd when Arch first switched, but I learned to appreciate it (the simplicity of unit files won me over). This came about a year and a half into my journey with Arch Linux when I was still learning that the easiest way to use the distribution isn't to fret over change but to embrace it. Otherwise you'll be implementing fragile workarounds that break every time you update.
Though, journalctl still annoys me.
Sure, I can understand some of the hate directed to systemd simply on the merit that it does* do things differently--but it's hard to believe that the vitriol and insults from the anti-systemd camp are likely to help anyone's cause.
Personally, I like it, it works, I've not encountered the stability issues or other bits of weirdness some folks seem to insist regularly occurs (maybe it's distro-specific), but I'm also OK with being a statistical outlier. Or perhaps the anti-systemd crowd is disproportionately noisy.
> Yet the oddly amusing part is how systemd isn't difficult to learn. The only valid complaint against systemd IMO is its departure from Unix philosophy, but for some parts of the \*nix ecosystem, I can't help but think that boat sailed long ago.
This is what I say when people complain that systemd "isn't Unix". Neither are package managers, but I don't see anybody saying we should revert to passing around tarballs that unpack onto root (other than Patrick Volkerding).
> [...] the easiest way to use the distribution isn't to fret over change but to embrace it. Otherwise you'll be implementing fragile workarounds that break every time you update.
I'm thinking about putting together a talk about exactly this, tentatively titled "MacGyver-Driven Development". It's my response to people who respond to any criticism with "Yeah, but then you can just put some tools on top of it": relying on tools only adds another dependency that makes your system more fragile and resistant to change.
The proper way to develop is to keep what you do as small and environment-agnostic as possible. That way, when tides do change, you don't have to fight them or work hard to embrace them; you can just go with the flow, and just change the few parts that touched the changing dependency.
> "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork".
Even if this claim were actually true -- what's wrong about that? Why should someone move to a new immature system if his current one works perfectly for him? If an Apache server works perfectly for me why should I invest time and effort to switch to nginx just to get the same thing?
I consider a fork a good idea because it would split Debian development into a safe area of old-fashioned reliable technology, and a testing area of new technologies like systemd. If those new technologies have proven their reliability _then_ the moment has come to think about exchanging old stuff. It is too risky to throw a reliable system overboard and to force all people into an immature new technology.
I wonder what's the problem with the systemd proponents. If other people prefer SystemV why don't they simply let them go?
Compare that mentality to trying to get a big new subsystem into the kernel.
Torvalds is likely to require you to hammer out all the details and debugging in a separate tree. This even more so if it is replacing a tested, stable and maintained subsystem.
As such, it is the Systemd proponents that should be doing a fork. And run it alongside stable for a time to demonstrate that it works. Then people can move over at their own pace.
Your log files are binary already. What do you think 'cat' is, other then a binary log reader?
Binary log files are as easy to read as ASCII with the right translator. Tagged binary formats are easily and trivially self-describing, and as resistant to corruption as ASCII.
The problem is, people think they'll be able to understand corrupt ASCII logs, but in reality basically never deal with them. They deal with truncated logs - which, well guess what, can be handled just as easily as for binary logs.
Given that journald can be configured with a log size of 0, and to output everything straight to syslog, this is such a non-complaint it's absurd. Especially when the hot thing in syslog management is usually to stream everything into a database of some kind to make it easy to search!
EDIT: Oh yeah, and this is assuming you're not compressing your logs. Which you probably are. In which case, they're already a very complicated, very corruptible non-binary format for which you have to use a fairly complicated read app (zcat) to access.
> Tagged binary formats are easily and trivially self-describing, and as resistant to corruption as ASCII.
The advantage of human-readable logs is that the semantics and rules of the language it's written in serve as a built-in forward error-correction measure. It's easy to see that the string "the qu()&!`8zwn fox jumps over the la" is a corruption and truncation of "the quick brown fox jumps over the lazy old dog", especially if you're already used to seeing the original string under normal operation. By comparison, it's much harder to tell whether or not an arbitrary byte string is corrupt, and journald does not make use of any forward error-correction measures to assist in this.
> Given that journald can be configured with a log size of 0, and to output everything straight to syslog, this is such a non-complaint it's absurd.
If I'm using journald in this configuration, then why does journald need to exist at all? It's literally dead weight, and adds another point of failure to my logging facility.
> EDIT: Oh yeah, and this is assuming you're not compressing your logs. Which you probably are. In which case, they're already a very complicated, very corruptible non-binary format for which you have to use a fairly complicated read app (zcat) to access.
When compressed log corruption recovery is a concern, tools like parchive [1] are used instead of gzip/zcat.
Good points. As for compression: I think most people compress logs post-rotation. So you'll be unlikely to have a corrupted compressed log. Either the file will be compressed, then then original removed, or compression will fail, and the original will remain untouched.
It's more of an issue with whatever is written to disk by running processes. As you point out, it's debatable whether or not unicode/ascii vs "binary" is a sensible distinction ... I'd say taking a hex-editor to a mangled but mostly ascii text file is easier than some (any) binary format, but perhaps you know of some easy-to-use tool that will take a file-description and give you back data? Things like figuring out integer encoding and offset for timestamps across different files etc... is much easier with a rather redundant ascii timestamp than some binary number?
If your filesytem eats your files... well then that's a different problem.
Exactly my point: this isn't a complex database format. It's a tagged binary format, written in an append only fashion. So you're only going to lose data if the tool decides to write bad data, but that's just as true of a text log format - your logs are useless if all those numbers don't actually relate to the values they claim to.
So any tool which can read a journald journal can happily do so until it hits hard corruption - which is about as well as you ever do with syslog. I'll gladly trade an unlikely and really narrow recovery profile, for smaller, easily machine readable, well-defined log files (in the sense that, to write an entry, someone wrote down the exact struct somewhere, and had to keep using it that way. No regex's which fail in some case which happens once every 1 million lines of log file). Especially since the compatibility layer is just "forward text logs to syslog".
Fair enough. But you still then need to fit an additional tool into your recovery image. As long as it is possible to do with a small static binary that can be expected to be available (say built into a version of busybox) I don't have a great problem with it.
> A fork, or an alternative init system, could be a good solution.
I consider this a good idea. Servers and desktops are two different things so why not have two different Debian versions?
This way Debian Server could be kept small and simple while the systemd developers could continue without any restrictions. If they go too far then we could use the Debian server and add our own desktops to it.
A lot of the components mentioned are actually optional and you can build systemd without them or disable them at runtime. I'm guessing this idea that this idea that systemd is targeted for the desktop is from the logind kerfuffle with GNOME and friends but it's actually an optional component. If anything though systemd is more targeted towards server market.
This. SystemD means you can boot the system without needing a shell installed at all which is what Debian has been proposing moving towards for a very minimal server image.
Fine. There speaks nothing against Debian Desktop for servers by admins who prefer systemd. I am current happy Debian user myself, and I would use such a system for my desktop.
However regarding servers I agree with the Unix veterans that Unix(-like) systems should be faithful to the KISS philosophy which made Unix so great. The IT world has become very complex, and we should not make it more complex than necessary. Debian and its derived distris took over the server world, and (AFAIK) it accomplished that with SystemV not with systemd. So SystemV is not that bad.
> However regarding servers I agree with the Unix veterans that Unix(-like) systems should be faithful to the KISS philosophy which made Unix so great.
Unit files are surprisingly powerful and simple and follow KISS quite well (they're easier to maintain). systemd is also not quite as monolithic as some are wont to believe.
> Debian and its derived distris took over the server world, and (AFAIK) it accomplished that with SystemV not with systemd. So SystemV is not that bad.
This just seems disingenuous. It's almost like arguing we didn't need nginx because the web server market was won by Apache, not nginx.
systemd has its warts, I won't deny that, but it seems that most of those opposed to it are opposed strictly on the merit that it's new and different.
In the total sum, systemd and it's declarative unit files, is more KISS than all the services coming with their own shell scripts, their own log handling, their own daemonization etc.
So I can imagine having very different init systems for desktops and servers if this means that the server won't be encumbered by a number subsystems which are of no use to it.
systemd is about choice ;-) Only use the subsystems that you need. For example, if you'd want to save some memory and time, you could use systemd-networkd instead of shell scripts and dhclient.
systemd is used in constrained environments like phones and embedded systems because it's fast and solves problems (e.g. watchdog chaining).
Someone disagreeing with you doesn't mean they are stupid, evil and part of a grand conspiracy to destroy everything you love. They just have different priorities. Why is this so hard for people to understand?
Because a lot of people are speaking very authoritatively, yet with little content, about systemd. They raise objections based on partial or inaccurate information. Various bans on discussion are happening precisely because it's apparent that a number of people are no longer interested in useful discussion, so much as creating chaos until they get their way.
Manifestly described by the idea that people without time to interact with Debian, are going to instead launch their own Linux distro.
If partial or inaccurate information about a subject was the criteria for not talking about it then Torvalds should have shut up about kernels and let Minix be the default for everything. Read the exchange between him and Tanenbaum and tell me it doesn't sound like two douche bags flame baiting each other with Torvalds sounding like he has no idea what he's talking about: http://oreilly.com/catalog/opensources/book/appa.html
The whole point of free licenses is to let half educated monkeys type away on keyboards because every so often you end up with Apache or Linux out of it, of course you also get pulse-audio and systemd but no system is perfect. If people like it more than Debian it will replace Debian, like Ubuntu nearly did before they went with unity and a whole bunch of other terrible decisions, if they don't it will die, and if it sticks around as a project with some users, like every other debian derivative, it will be a wonderful resource to find bugs.
In which case we don't need to debate who's spreading FUD.
But people who want to take part in a debate should expect be held to account for the things they say, and in the case of systemd a lot of people are spreading a lot of misinformation. That's forgivable, I make stupid mistakes and misremember things all the time, but it's sure starting to seem like there's a very casual disregard for the truth and with it, any possibility of solid debate.
Not to mention the usual crowd of trolls who are just happy to have something that'll start an argument.
Am I the only person who prefers systemd? Maybe because it's the only init system I've managed to get my head around. Other init systems seem so complicated. A config file vs a bash script is far easier and they all seem to require forking.
I only use Linux for servers so I may be unaware of a sane init system that works like systemd but isn't systemd. Until something like that appears, I'll stick to systemd.
I use systemd on all my servers. A couple of lines of declarative configure file to specify a daemon with its restart policy beats a messy shell script.
For my custom processes I've ripped out all the chroot, fork, and setuid code added in a couple lines for systemd watchdog and status support calls. I'm not going back.
Granted, journalctl with a filter is longer to type than cat. Someday I'll add nice alias to my shell rc.
I don't think you're wrong. I imagine all these people saying systemd is so awful are just worried that their hard-earned sysvinit knowledge will become obsolete and that new users won't have to go through silly bash scripts (that are totally secure of course - no chance of security vulnerabilities in something as ancient and wtf-free as bash). Instead they'll have something sane like this:
I think this Debian fork talk is a bunch of nonsense, but so is your comment. It's the classic "systemd or sysvinit" false dichotomy, as evidently a ton of Linux users have never stepped out of their cage to ever look at anything else.
Besides all the sysvinit alternatives (like depinit) that have popped up throughout the years, fixed most of its deficiencies and were promptly ignored, even having a shell-based boot doesn't mean you need to resort to the antipatterns that Linux distros have been doing - look at what the BSDs do with /etc/rc.subr and rcorder(8). Though, to some extent, this can be blamed on sysvinit's flawed abstractions.
If anything, making a "systemd or sysvinit" dichotomy only tells me you're unknowledgeable.
You're totally right about the false dichotomy, but I don't see why you think other init system were ignored.
Debian used a really open process to decide the new default init system where every developer could propose any init system provided that someone offered to maintain it.
Since SysVinit, systemd and Upstart where the only ones with a credible maintainership (OpenRC didn't work on Debian until a few week after the discussion started) the discussion was centered on those three.
So it's not like other init system were ignored, it's just that noone bothered to do the actual work to make them suitable replacements.
My hypothesis is that systemd was the first to provide enough benefits to motivate people to implement the switch in Debian.
From a distribution maintainer the fact that systemd tackles many loosely related problems is an actual benefit, since now said maintainer just need to coordinate with an upstream project instead of having to maintain dozens of special snowflake systems (eg. to set the hostname). This is what most systemd critics fail to accept.
Oh, and the shell is nice but it's one of the worst languages to implement anything non-trivial, http://www.dwheeler.com/essays/filenames-in-shell.html is enough for me welcome the idea of getting rid of it in the boot process. :)
Doesn't it do logging? And cron? And login/console? And configure network interfaces? And a bunch of other stuff...
... systemv sucks enough that I'm in the middle of re-working our firmware at work to use systemd instead (I do like socket activation and supervisor stuff), but of all the systemd features one could like, "do one thing and do it well" isn't one of them.
only the journal is a required additional feature of systemd, and you can set it up to not store anything and just forward to your syslog/rsyslog/...
you don't need to use systemd-networkd, it's a separate program - but it's better than debians /etc/network/intefaces adn RH /etc/sysconfig/network-scripts/if* - so I do welcome the consolidation it'll bring to distros.
you can still run normal cron
you don't need to run the kms console daemon either
The idea is that rcNG makes things simple, but it doesn't stand on your way if you want something more complex or in this case you want to make it harder to use than it needs to be.
Config test is a human operation; you manually do it after you've edited the configuration, and if you've forgotten to do it then the next start will crash. It makes no sense to automate configtest.
Sure it does! It's a belt-and-suspenders approach that ensures that human error won't cause your system services to become unavailable. Why use a computer unless it automates tedious tasks for you and remembers to do things that you might forget?
The Gentoo OpenRC BIND 9 init script runs named-checkconf every time you try to start or stop the BIND service or reload its configuration files.
This automatic check has saved me a bunch of time and mental overhead over the years. The auto-check has also prevented some downtime when I -inevitably- fat-fingered something in a config file.
Looks to me like all Systemd does it move the logic from the init file itself and into a binary blob inside init.
And that blob is going to be harder to debug, never mind fix, on a production system. While your manager is breathing down your neck about getting it back up ASAP.
How does systemd handle situations where you need to check for the existence of directories and check their permissions, etc, before starting the service? You'd have to script it... and it would end up looking like a sysvinit script anyway.
You can add ConditionPathExists= or ConditionPathIsDirectory= to a Unit to check if one or more directories exist. You can also substitute the userid into commands with %U, so you could have it always chown before running the command, as you can have multiple ExecStart= directives.
At this point I don't really want to touch the systemd argument with a barge pole anymore, but I think it's worth saying that I'm a lot more comfortable with the sysvinit script.
After a lot of years of maintaining and editing and writing configuration files for more Linux daemons and applications than I can remember, my least favorite are the ones like the top example, that have a pile of predicates and values. They require careful reading of documentation to look for any traps and gotchas (the documentation always has a fine print section buried deep within it somewhere that says, "oh, by the way, you can't foo with a bar setting because that will cause a baz to foom"). You have to either memorize a bunch of variables specific to a single application, for a ton of applications, or you have to spend time referencing documentation (and re-reading it for those gotchas) every time you open the config file. There's also the nuisance of new predicates in later versions, hidden and undocumented predicates, and on and on.
It's just a pain in the ass. Really, as much as I love Postfix otherwise, it is the poster child for why this approach sucks monkey. Here's the documentation for Postfix: http://www.postfix.org/documentation.html ... let me know when you've read and understood all of it. :-)
But the sysvinit file on the other hand is easy. It looks uglier, but only to people that aren't accustomed to shell scripts. I can take one look at it and know what most of it does, because all other shell scripts do similar things.
And here's the best part! If the shell script seems to be broken for some reason, I can debug it! I can stuff some stdout or stderr in there; I can call my own binaries or reference other shell scripts; I can do programmer-y things to it!
The default response here is usually, "well, we'll just keep the configuration file simple then." But that never happens. I would bet a donut that, years and years ago, some Postfix developer said, "the sendmail configuration system sucks, we'll do our own, and we'll just make sure it stays simple."
But software never gets simpler. It's a steadfast law, a more universal rule of reality than the arrow of time. Software only moves in one direction, and that's towards more complexity. The safe bet is that ten years from now, those systemd configuration predicates will have exploded 10-fold, with lots of hairy edge cases and gotchas and hidden or poorly documented interactions, because that's what always happens. A shell script on the other hand will still be editable; the Apache sysvinit script you posted doesn't do anything that a shell script couldn't do 15 years ago.
I'm really beginning to think this whole systemd thing is actually a culture war between two different generations of sysadmins. The older, bearded generation wants to stay with the thing that has always worked out for them in the end, and the younger, nicer-smelling generation wants to do something new because they haven't made enough mistakes yet.
The system script posted is actually a fairly bad example because that one just use apache to manage the process. Where systemd shines is where we don't need specific purpose binaries to manage each service.
[Unit]
Description=A network traffic probe similar to the UNIX top command
Requires=network.target
ConditionPathExists=/var/lib/ntop/ntop_pw.db
After=syslog.target network.target
[Service]
Environment=LANG=C
ExecStart=/usr/bin/ntop -i eth0 -w 3000
Type=simple
StandardError=syslog
[Install]
WantedBy=multi-user.target
Note the lack of pid files of stop commands etc...
> And here's the best part! If the shell script seems to be broken for some reason, I can debug it! I can stuff some stdout or stderr in there; I can call my own binaries or reference other shell scripts; I can do programmer-y things to it!
systemd captures stdout/stderr and the exit code you rarely need to run it outside of systemd. Most of the time the ExecStart command would do the trick.
> I'm really beginning to think this whole systemd thing is actually a culture war between two different generations of sysadmins. The older, bearded generation wants to stay with the thing that has always worked out for them in the end, and the younger, nicer-smelling generation wants to do something new because they haven't made enough mistakes yet.
Or alternatively they've seen the millions of issues you can get with sysvinit scripts that aren't perfect and decided we can do something better.
No. I even gave a talk about how I came around to liking it at linux.conf.au this year. And I am a veteran *ix sysadmin.
Something I have noticed is that most of the loudest anti-voices have no actual technical arguments against it, and generally haven't even run a system with it for a month; you can tell because so many of them clearly don't even know the most basic syntax.
No. It's just that the people who want to get systemd and those do not care deeply about their init system have left and only those who see it as a threat to linux still bother.
The anti-systemd-brigade only seems to be a small minority of Debian devs (though they're very loud, and very persistent), so I'm not sure it would have much effect on the project as a whole.
If a fork would reduce the time spent arguing about the init system (which 99% of users don't care about), it could even prove beneficial for Debian.
[It seems unlikely the fork would attract the critical mass of devs/users to succeed on its own though.]
I'm not even "anti-systemd". I'm actually in the process of implementing systemd for the firmware of an embedded target in $dayjob because socket activation is actually a good idea and happened to work well when I played with it.
But a switch to a different init system shouldn't break your system so badly that it no longer boots. And yet that's what happens if you rely on keyscript to unlock your drives in /etc/crypttab.
You can still use a keyscript (I do), it just need to be done in a different way. Instead of putting the configuration in /etc/crypttab, which confuses systemd indeed, you can still use the kernel cryptopts variable. For example, in the grub configuration add something like:
Anf then in /etc/fstab use the /dev/mapper/<target> (sdc5_crypt in the example above) as the root device, as before.
Then you need to make sure the initramfs contains all the tools needed to support this (that was done automatically with /etc/crypttab, it's "manual" with the kernel option). To do this, add under /etc/initramfs-tools/hooks a script file to load what's needed in the initramfs: cryptsetup, passdev, the needed kernel module. You can roughly copy the existing /usr/share/initramfs-tools/hooks/cryptroot and simplify it.
I've seen other distro documenting the kernel approach instead of /etc/crypttab for the root filesystem. It may become the standard way in the future, and there's no reason it couldn't be fully automated. There's some coordination between several components so it may take a bit of time to converge to an accepted and supported way thought.
Thanks, I appreciate the hint, I should have noticed that a kernel parameter would be one way to do it (I'm familiar with writing initramfs-tools/hooks to make the existing keyscripts work).
The fact remains though that a wheezy dist-upgrade is going to ruin your day badly enough to spend some time digging up your iDRAC/whatever creds (admittedly, nobody is going to dist-upgrade their prod servers without testing first... or are they? :P)
During boot - before the rootfs is even mounted, what kinds of exposure are you thinking of that's worse than the shell scripts which already make up cryptmount labyrinth? Some sort of `() { :;};` response from the smartcard I'm querying? If I can control the smartcard response, wouldn't I also be able to crash a similarly badly-coded custom C program which does the same?
Only in the future it may use kdbus for some purposes (eg. uploading firmware blobs), but this will only affect internal interfaces.
On the other hand, systemd does not require the D-Bus daemon when you're launching systemctl it as root, the D-Bus daemon is only needed to route the call when used by unprivileged users. When used as root, systemctl connects to the PID1 socket directly and D-Bus is basically just a serialization protocol (and systemd does not depend on libdbus either).
To be fair, udev communicates with the kernel via netlink. All the userspace notifications are done via dbus. So dbus was already part of the equation whether people realize it or not.
You raise a good point. I hadn't considered a shell based init system where the shell scripts only run at startup and aren't available to run at any other time.
You mentioned smart cards... what system would handle when you connect a smart card after boot?
The trigger is the appearance of the volume. If the mounter actions crypttab properly it'll run the keyscript which challenges the smartcard or TPM or USB crypt token or some combination thereof, which in turn provides the response to cryptsetup.
By default nothing happens when you insert a smartcard; if the keyscript tries to run without the smartcard it will retry, timeout, and eventually fall back to askpass. If there's a LUKS keyslot with a backup passphrase which can be entered by a human operator at the tty, this also serves as a disaster-recovery mechanism so that you can afford to lose the LUKS keyslot associated with the token/smart card.
I'm sorry. I wasn't clear. I was asking about the work that gets you to the point where the volume appears. You don't necessarily have a device file for the volume, so something needs to be ready to handle that logic when the device is inserted, then when it has figured that out, you have to notify the automounter that it is time to go to work (or not), etc.
Now add logic so that all of this magically gets powered down all the time to conserve power (and then figure out what you do with the filesystem when that happens).
Now handle the case where you have a bad connection so it is constantly flapping as inserted & not.
Now handle the case where it gets ripped out with no warning.
Now handle the case where you have a smartcard and you are using it to provide the key to decrypt another smartcard...
I think I get your point, but for what it's worth the sysvinit cryptroot/crypttab setup has worked seamlessly for servers for years. Basically if keyscript fails (smart card not available or challenge material not available or TPM won't unseal) it falls back to ask pass on a TTY with the hopes that you can type something in.
I also do appreciate the systemd features for mobile and desktop devices.
But the sysvinit mechanisms aren't rendered completely irrelevant by systemd; the sheer stupid dumb luck of the the thing is actually deterministic and repeatable in my experience. systemd migrations have exposed hidden dependencies I hadn't previously had to worry about between services, which is good in one way, but not necessarily good in other ways (transient intermittent failures which never occurred under sysv).
Yes, it's unfair to blame systemd for poorly defined services - I do like the concept systemd is offering in that respect. But if I have servers in the rack which have smart cards in them that I know are always attached except for very rare events where a sysadmin will be dealing with things, I don't think there's harm in a 4-line shell script failing maybe once or twice in a server's lifetime if it means not having to maintain bespoke C programs for years and years
Racy code has issues with race conditions. Any error in setuid executables can be very dangerous, so they are strongly discouraged. However, once you've decided that you have to write a setuid program, there's no particular reason to not write it in a scripting language.
As a datapoint, the KDE folks think that using scripting languages for setuid executables is okay:
/usr/lib/kde4/libexec/fileshareset: setuid Perl script, ASCII text executable
> The anti-systemd-brigade only seems to be a small minority of Debian devs (though they're very loud, and very persistent)
The pro-systemd brigade only seems to be a small minority of Debian devs (though they're extremely loud, and trollishly persistent).
I've thought for a long time that they must have a place where they all hang out in secret and share links to discussions where they need a pro-systemd response / a handful of downvotes.
In this way they give the impression that their numbers are much larger (the reasoning here is that for any given post or discussion, if the number of "ambient" / "organic" critical comments or downvotes that it receives is a proxy for how critical the community at large is, so by sharing links they make it seem like there's a broad base of support for systemd).
This kind of thing seems to happen periodically, where a person / group of people railroads a decision using methods that are outside the "accepted" set of methods for OSS development, namely meritocratic discussions.
Who knows what their motivations are. It probably varies per person. Having "I designed and implemented a new init system and got all the major distributions to adopt it" on a resume is a huge demonstration of "impact", which is something that really pays off in a lot of companies / organizations.
Decoupling systemd is a feature desired by system administrators, who are responsible for installing and managing most debian and debian-based distros.
on the contrary, systemd is a feature desired by system administrators, who are responsible for installing and managing most debian and debian-based distros.
There's a whole lot of "I don't/do like it" and "It did/didn't work for me" but not a lot of explanation of why they do or don't like it, or what didn't work, and I'm interested in those details.
Is that because you think it's somehow technically inferior or because you you've learnt a whole bunch of skills and don't really want to have to replace them? I mean, would you like to see the init system change, period?
I have. I ran Arch for 3 years, up until 3 months after they implemented systemd. It made a KISS situation incredible complex. I switched back to Debian on my desktop after that. If Debian switches to systemd, I'll switch to Slackware, until SystemD has proven iteself to be stable and simple to administer. Not before.
I've installed systemd on Debian testing months ago and have not had a single problem. https://wiki.debian.org/systemd has some hints.
I think it's likely when Jessie is released you'll most likely find that stuff still works.
I saw that as a giant red warning flag as well. Why would I expect them to maintain a fork and ensure it has full sysv init support, if they don't even have the time to engage in the current process?
It's all a bit overdramatic anyway - there are heaps of Debian forks; they're called 'downstream distros'. Ubuntu is one.
> Why would I expect them to maintain a fork and ensure it has full sysv init support, if they don't even have the time to engage in the current process?
Probably because they (experienced Unix veterans) realized that it makes much more sense to test the demand of a fork (that's what they made the website for) than to continue any useless discussion about systemd. Some systemd proponents obviously have serious problems to make a sober discussion anyway (interestingly also in a prominent German forum).
Notice: "If SystemD will be substituting SystemV in Debian, we will fork the project and create a new distro: Pure Debian by Veteran Unix Admins. We hope this won't be necessary, but we are well prepared for it."
They are not eager to make a fork but I think they will actually do it if necesary.
Using the same argument, forking would seem like a horrible idea if there isn't active maintainers.
Until I saw that line, I was thinking: well quit talking about doing it, and just do it!
The idea of a non-systemd distribution in general is something I've been expecting to pop up for a while. And if the vocal people online represent a real desire not to switch, then one really should exist. Beyond that I'm rather uninterested in such a project one way or another.
The trouble here is that the bulk of the work is just maintaining a changeset to debian packages. They haven't even spun up dak and friends, so I'm assuming this is DOA for now. It seems like a lot of hot air to pressure debian, or at the least attract contributions that can maintain their fork. Is "fork" a scary word to any DD, considering debian is already the upstream distribution for other, more popular, derivatives?
The website could be replaced by a much shorter version simply stating "I dont like SystemD. -anonymous".
The author is essentially making a threat, that there will be a fork of Debian if the project does not give in to his demands. Then he states that he is totally not just speaking for himself, but for a much larger group, and in fact claims to have the majority on his side. I have a hard time evaluating the seriousness of these claims, as there is no intend to back up any of this.
As far as the arguments go, there is nothing new here. The concerns have been stated before, and have been heard, too.
Go ahead and fork. Just leave me alone while I enjoy using systemd.
I think some people are taking this way too personal and overreact.
Forking is probably the best way to stop all the whining.
A fork would also mean that Debian (systemd edition) would not have to keep legacy init script support. You could have a 'clean' systemd in around Jessie+1 I imagine.
Debian already supports non-Linux kernels on which systemd won't function. So the legacy init support (or a compatible alternative) will still be required.
I find it very difficult to get behind a movement whose primary complains are that the status quo is "a slap in the face to the _____ philosophy" and "betrays the _____ philosophy" and so on. If you want to sway me, you have to tell me why your way is better. The alternative is "offensive" to you? I cannot begin to describe how much I don't care. You can tell a lot about a movement by those they stand with, and you've listed your them as "Harbinger of the Linux Apocalypse", a boycott, and finally something that does nothing but mock those it disagrees with. I mean you may be bringing up valid points but curb the drama, eh?
So I'm all for a fork. That is the point of open source, no? Go on and make a fork and if it's awesome people will use it, otherwise people won't. And maybe then we can curtail the endless arguments about this in Debian. But in spite of the title this article, it really didn't read like it was asking if we should fork Debian. It read like it was asking people to pressure Debian to follow the authors' agendas, with a threat (?) of making a fork if it didn't.
> It read like it was asking people to pressure Debian to follow the authors' agendas, with a threat (?) of making a fork if it didn't.
This. The point of this site seems to be the author begging Debian not to make him fork, because that would be such an imposition on him. It's the same threat as a child threatening to run away from home (except that parents have a reason to care about their child's life).
The main reason for forking seems to be opposition to SystemD. Initially I was unconvinced but then I remembered the recent story of Lennart Poettering (one of the authors of SystemD) on The State Of Open Source Communities where he describes the hostility towards him personally https://news.ycombinator.com/item?id=8414859
In light of that, forking is a more civilised approach than bullying and threatening the author.
> In light of that, forking is a more civilised approach than bullying and threatening the author.
Yes, but it is sad that the more straightforward approach of contributing back to the community isn't taking hold.
If you are worried about mission creep... you help stamp out a very clear mission. If you are worried about bloat, you contribute patches. If you are worried about a nasty hairball... you contribute code reviews. If you consider C code less readable than Unix shell... please don't reference the Unix Philosophy as the principle behind that thinking.
Lennart Poettering is a bully himself, with a well-documented instance where he continuously interruped a talk at the 27th Chaos Communication Congress, even going as far as taking over the stage while insulting the presenter. Lennart Poettering is a toxic person, toxic to the OSS community, and he's the last person that can complain about bullying.
This is the talk you mean right? Have you actually seen the talk? Yes, Lennart interrupts the talk but everything he says is correct, while the presenter just spreads random FUD.
The presenter clearly shows that he doesn’t understand most of the stuff he talks about, talks about 3 year old bugs that already got fixed, etc.
Yes, it’s not the nicest way to interrupt a talk, but the presenter should have expected some kind of reaction, given the controversial headline.
People like Lennart put their heart into their software. If you shit all over it and spread random FUD, you can expect some response. What would you have done?
Also he doesn’t “take over the stage”. He comes up after the talk has ended, because people on IRC asked him to.
The way Lennart interacted with the speaker during that talk was extremely inappropriate. If he had corrections to make he could have arranged a short talk afterwards or a written blog post. It is very poor form to be so disruptive to a speaker, no matter how much you disagree with them.
No it isn't.. being on a soap box doesn't give you some special permission to just spread false information without being interrupted. I heard this argument before, there was an article about book reviews, and that authors who interacted with reviewers (by writing on their own blogs about them or on twitter) would be labeled Bad Behaving Author and be shunned by the review community. What's up with that?
If someone talks shit, he should be challenged as soon as possible, preferably in front of the same crowd they are talking shit in front of. If you take the opportunity to talk in front of a lot of people, you should also take the responsibility to be properly prepared, and be ready to face the consequence of not performing adequately.
Let's get this straight: he's not on a soap box (a term that refers to people who shout at passers by on the street), but rather at a conference at which he was invited to speak. The audience came into the room to hear him give his talk. Lennart rudely interrupted this.
> I heard this argument before, there was an article about book reviews, and that authors who interacted with reviewers (by writing on their own blogs about them or on twitter) would be labeled Bad Behaving Author and be shunned by the review community.
That's not my argument at all. I specifically suggested he _should_ respond with a blog post. Don't put me in the same group as those people. I encourage anyone to share their views on their own blogs, in comment sections, and on Twitter.
> If someone talks shit, he should be challenged as soon as possible, preferably in front of the same crowd they are talking shit in front of.
I disagree that it is appropriate to interrupt and shout someone down just because you think they are "talking shit". The definition of "talking shit" is subjective. If someone is interrupted before they can make their point, then the observer does not have the ability to judge whether they are right or wrong. It instead becomes a matter of whoever has the best rhetorical tactics. (Or who can shout the loudest.)
My job involves giving a lot of talks, and if someone were to engage with me like this I _would_ be prepared: I'd be prepared to tell them to wait until I have finished my talk and address their comments afterward. This has happened many times, and it worked out fine for all involved. It's called civility.
> Let's get this straight: he's not on a soap box (a term that refers to people who shout at passers by on the street), but rather at a conference at which he was invited to speak. The audience came into the room to hear him give his talk. Lennart rudely interrupted this.
I was actually there and the talk was so much better for this. Also, I don't think the Chaos Communication Congress is that much like a business conference. It is hackers and people who care about software, not so much for proper manners.
If I remember correctly, Lennart specifically came to the congress because there were rumors before that this talk will be bashing Lennarts software, so it was no surprise to see him show up.
You mean that famous talk when the very poorly prepared presenter ("Datenwolf") took the stage to trash-talk and spread misinformation about large parts of the Linux Desktop, evidently oblivious to important requirements like accessibility that modern desktops such as Gnome and KDE are designed to meet, which LP had to correct by comments?
Yeah, especially if everything what he wrote there was like that bitcoin hitman stuff, which turned out to be just a line like "maybe we should start btc fund?" from IRC written after someone else complained about issue with systemd by guy known from his funny trolling there - and absolutely nothing more than that.
While at first I felt a bit sorry for him when I read that post, after I learned about what exactly was that "hitman threat" I lost any remaining respect to Poettering. That's just grabbing attention and playing victim. He deserves negative response for that.
> I'd really welcome the anti-systemd ranters to just do some work that makes them feel happy, such as making a new distribution that has the exact init system they want.
Most people are already working on things that make them happy. The frustration here is that the tools they depend on are changing... in a way that they don't like.
They also have limited time for projects. Any time spent fixing other peoples projects is time they don't spend on their own projects.
I left the Linux desktop world nearly 10 years ago, for these kind of reasons. I use a Mac as my desktop, because I don't have to fight with it. 99% of everything works, and the other 1% breakages are ones I can live with.
You know, provided Apple continue to agree with you...it seems more like you're just zenning over the fact that even if you did disagree, you couldn't change anything.
Choice is widely regarded as actually making people more unhappy.
EDIT: It's also an ironic comment, since a frequent criticism of systemd is that it's trying to be too much like Apple's launchd.
I'm not "zenning over" anything. I need a computer to get work done. I don't need to be mucking with the computer to keep it working.
My choice is to use a (mostly) closed system, because it meets my needs.
Other people don't like systemd because they feel it removes their choices.
There is no contradiction in the two approaches. There's also no irony.
If Unix had started out with something like systemd, fewer people would be complaining about it now. It's the change that people don't like. And the apparent removal of choice.
forking is a more civilised approach than bullying and threatening the author.
Absolutely, in that almost anything is. :)
But specifically, at this point I'd really welcome the anti-systemd ranters to just do some work that makes them feel happy, such as making a new distribution that has the exact init system they want.
I suspect that Debian would love for them to do that as well. Debian is in general welcoming of downstream distros since the downstream distros—if given proper care and feeding—often feed back useful improvements to Debian.
The problem here is that no one is actually doing a fork (yet). Some of the same loud, uninformed minority have just created a ranty web page that presents a skewed view of history and makes threats. It's just more of the same interminable mailing list snarks but in web page format.
Trying to put out and support an entire distribution may serve to broaden their minds as to the delicate position the distribution is in with regard to integrating upstream work into a coherent whole.
Sadly I'm not convinced that any enlightenment is going to be achieved because the people behind this web site admit that they haven't even got the time to become involved enough in Debian to have a vote, so I don't know where they're going to find the time to launch a non-toy distribution.
Not so convinced by this. "Those days are dead and gone and the eulogy was delivered by Perl." -- Rob Pike
Systemd in debian would have an easier time making friends if it didn't usurp PID1 for roles that are currently outside PID1, and if it didn't encourage software which is currently init-system agnostic to grow a dependency on a specific init-system implementation.
Also, critique starts with "We like controlling the startup of the system with shell scripts that are readable".. How on earth is a systemd service file less readable then a hundreds of lines bash script?
Being a developer and being an admin are completely different jobs.
A admin needs to know a dozen languages and codes in bash most of the time, they have a hand written folder with glued in scraps next to their terminal which explains why they did what, how and why. This folder has entries like "reboot three times, do an rain dance and run godHelpYou.bash as root" because that's the only way that you've found out how the libraries actually talk to each other.
For people like this "do one thing and do it well" is the only way that you can beat the impossible complexity of a modern machine back into a running computer even some of the time. When you have a single point of failure which is a black box you're just back to windows land: restart the service, reboot the computer, reinstall the system.
From this point of view devs look like a tribe of monkeys building a shit pyramid over your village. They just keep flinging more shit at the top thinking they are the greatest ever monkeys. When the shit pyramid collapses and buries everything you know and love under a few meters of shit, probably killing someone in the process, these monkeys just shrug say a few words about how that was the best shit pyramid anyone had ever build and start making a new one one or two valleys over.
For people like this "do one thing and do it well" is the only way that you can beat the impossible complexity of a modern machine back into a running computer even some of the time. When you have a single point of failure which is a black box you're just back to windows land: restart the service, reboot the computer, reinstall the system.
For the developers, on the other hand, it might mean that some use case that is important for the admin is simply not yet implemented. The solution, as so often, is... drumroll to report a bug! Developers care about their users. Just talk to them.
Also, admins should realize that "reducing complexity" is a goal that they share with the developers. systemd is all about reducing complexity by implementing functionality the right way, on the right layer. For example, with systemd it's way easier to write a daemon, because it takes care of
* daemonizing: just stay in foreground
* logging: just output to stdout/stderr. journald will collect everything, and if you want, forward it to a classic syslog service
* startup: no more shell scripts required, just a simple service file
* supervision: just add "Restart=on-failure" to your service file. It also supports software watchdogs.
And what happens when that single file doesn't work? The one time I had to deploy a custom service using systemd, there was no feedback as to why it wasn't working with service start. No error message, no guidance on how to debug online, no indication of where to look. By contrast adding it to a shell script just worked.
An init system should have a verbose mode that tells you exactly what steps are being taken to start a service and what the result of each step is. Maybe this will come later, but -given the guy's history- it won't be written by Poettering.
you're seriously suggesting strace as an acceptable form of troubleshooting?
Don't get me wrong, I love to bring out strace and will use it to solve all sorts of problems, but it really shouldn't be necessary use it near the start of troubleshooting.
Different people have different definitions of complexity. For me having a single point of failure is complexity, for most people a centralized single process handling as much as possible is simplicity. Neither is right or wrong.
Whether a system is tightly coupled is independent of whether it's implemented as a single process. Objections to systemd as monolithic, as constituting a single point of failure, etc. are based on its being a tightly coupled set of components.
That systemd is tightly coupled is a valid objection, but "single process" has a specific meaning in this context and it implies a much worse design, with every component potentially taking down PID1. As far as I know, this is not the case in systemd.
Just curious, have you ever used systemd and ran into a problem where your service file screwed up and you had yo read systemd's source code or are you making this up?
I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out.
took me some time to figure out it was systemd.
the firewall wrapper for iptables gives you an insecure default config and is hard to fix via config management "add a service that means port 3128 TCP, now allow incoming connections"
My config management system creates files and pushes them out, I'm not in the habit of running idempotent commands repeatedly.. I'd rather check if something is correct before correcting it.
> I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out.
> My config management system creates files and pushes them out, I'm not in the habit of running idempotent commands repeatedly.. I'd rather check if something is correct before correcting it.
You should be laying down a base initial configuration at the time that the machine was provisioned. The basic example of this is the sudoers file. The default setup for Ubuntu/RHEL is different enough that it was causing problems and the solution was simple - force defaults.
> And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script.
Surely the systemd equivalent would be delving into the source code for dash, or god help you dash... I know which one I'd prefer--not that I've ever hard to do either, fortunately!
> And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script.
? You end up diving in to the service file vs. the script.
> And don't get me started on binary log files.
Having worked with binary and plaintext log data for the better part of a decade now, I have to say that pretty much the entire set of claimed advantages of plaintext log data is very wrong, and we've wasted a ton of productivity & efficiency because of it.
If you really are sure of its superiority though, just put a little stub in front that converts the binary log to a human readable format that still needs a program in order to present to the user...
> SysVInit has served me thus far with no issues.
Speaking of attitude... there are two ways to look at that datapoint...
And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script.
That's a good thing, because if you find a bug, it will be fixed for everybody, not just for your one-off init script.
your attitude is the problem
The attitude here is to fix problems at their source. Instead of using the hammer for everything, sometimes coming up with a new tool is a better idea.
That's a good thing, because if you find a bug, it will be fixed for everybody, not just for your one-off init script.
Generally I agree with this at a broad level. But, there is still the problem of: I need this running now. To do that, I need to compile and run a custom systemd, and hope that my patch gets accepted upstream, and that in a few months my distro finally adopts it and puts it in the standard package.
Generally speaking I really like systemd and am excited to get some time to update my installed stuff to use it, but the above is a real concern.
We have SysV shim layers for that though. We had them in Upstart, and we have them for SystemD. Boiled down, it can still run shell scripts that look like SysV scripts, and will be able to do so indefinitely because that's basic functionality.
At the worst case though, this reduces systemd to a shim-launcher for SysV init, which is the situation you find yourself in now or when using Upstart, which tons of Ubuntu users already have been.
I dare you to tell my why lxc-docker silently fails to start at boot in jessie. Without a single shred of clue in any log, no matter what logging options are turned up - at least with a shell script I can add some echo/exit/touch etc. statements to convince myself it's at least being noticed at startup: https://groups.google.com/forum/#!topic/docker-user/bg5-hlmR...
> I dare you to tell my why lxc-docker silently fails to start at boot in jessie. Without a single shred of clue in any log, no matter what logging options are turned up - at least with a shell script I can add some echo/exit/touch etc. statements to convince myself it's at least being noticed at startup: https://groups.google.com/forum/#!topic/docker-user/bg5-hlmR....
Have you tried adding "touch" commands in ExecStartPre/ExecStartPost? Systemd also gives you a hint of why something didn't start via "systemctl status $servicename".
No offence, but systemctl status isn't exactly new to me. The issue is that network.target apparently never fires any service which requires it (in Jessie at least). For what it's worth systemctl status docker shows it's just inactive (dead) - journalctl similarly shows no clues at all. I have a Debian pressed.cfg & virt-install script to reproduce if you're interested, https://gist.github.com/csirac2/f6e4ac6e7c715243d4b8 and https://gist.github.com/csirac2/57a1ddf7931fa3e9d17a although these aren't up to date with what I've been preparing for a bug report
The next step in troubleshooting that one is to run strace and find out what's happening. I agree it's frustrating but if no one debugs these things, problems won't get solved. (and yes, scorching the earth and installing a different distro is a valid solution to the problem at hand)
I'm not sure how to make strace pid 1 :-) And I'm not quite ready to abandon Debian yet. I've created a virt-install script which reproduces the problem reliably (honestly all it does is install jessie, then lxc-docker). Hopefully my workload eases and I can put this trivially reproducible thing into a bug report somewhere (debian? systemd? docker) for somebody to see what's going on.
FWIW systemctl start docker works fine after the system has booted. It's configured to require network.target, and even though I can see network target scroll by during boot, it's still not being noticed.
The work-around is to make multiuser want docker, then I've got docker starting at bootup.
Sounds like lxc-docker.service simply wasn't enabled. "enabling" is basically creating a symlink from multi-user.target.wants to lxc-docker.service. This is done by 'systemctl enable lxc-docker.service' once that service declares WantedBy=multi-user.target in its [Install] section.
Other symptoms that would indicate this was the problem would have been that 'systemctl status lxc-docker.serivce' would have said "Loaded: loaded (...; disabled)" and "Active: inactive (dead)". i.e., systemd never started the service because nothing ever wanted it.
strace -p1 should do the trick, you can attach after start, but you will have to get it started early, probably as a systemd service. Or if its in a container, strace form outside the container.
Without doing any further investigation: does the type of service you're setting in your user file match the way you're starting up the daemon? For a "normal" service, you need to start the service as "normal" and have it run without forking / exiting (as systemd handles daemonization).
If you start a "normal" service using a command that double-forks and immediately exits (like a `--daemon` flag), systemd will see that the process has exited to mean that the service has finished, and will terminate any of its child processes (as you want runaway dependencies culled when a service crashes). This sounds like the behavior you describe.
I read the 'shut up' line in the post above yours as more along the lines of 'do something useful, post bugs, show some commitment' rather than 'shut up systemd is the Only Way'.
Perhaps the sponsors of the linked site are doing bug reports on packages like systemd-shim and others. Perhaps the upstream project members involved are ensuring that they have init scripts for systemv available. They could add a question with links along those lines easily.
This sentence (if it's not obvious) is a hint to invest energies into making debian work fine without systemd instead of countless whining and crying but in the end doing nothing.
There may be some people opposed to systemd, but there have been votes that saw systemd as the clear winner for the default init system. Why should the majority of users who are FOR systemd bending to some users who don't like systemd out of some philosophical view? Instead of behaving like a little child, people can work on letting Debian run fine without systemd (which IS the fact today, i can simply switch between sysvinit and systemd just by installing a package).
And in the end, you should remind yourself that this is only about the default for one linux distribution. You will still be able to use sysvinit if you like. There is choice. The majority wants systemd. The minority wants sysvinit. Only because the opposers are loud and make a lot of noise about this doesn't change the fact that they are a relatively small number. Changing the default is the only sane thing to do.
> people can work on letting Debian run fine without systemd
Arch switched to systemd about a year ago. When official distro packages are shipping with systemd service files by default, it means there is drastically less effort required on your part to maintain a systemd-based environment. It would take an experienced and dedicated crew to translate the systemd service files of dozens of upstream packages to Runit for instance. The enterprise level support just isn't there, whereas with systemd it is.
That being said, I like writing systemd service files. I just wonder what would happen if more distros pushed for, e.g. uselessd or Runit as the standard init system.
> uselessd (the useless daemon, or the daemon that uses less... depending on your viewpoint) is a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism. Basically, it’s systemd with the superfluous stuff cut out, a (relatively) coherent idea of what it wants to be, support for non-glibc platforms and an approach that aims to minimize complicated design.
> Also, critique starts with "We like controlling the startup of the system with shell scripts that are readable".. How on earth is a systemd service file less readable then a hundreds of lines bash script?
Bash scripts? Unless I'm really mistaken, startup scripts need to be written towards the POSIX shell. It's kind of like bash scripts except you pretend the year is 1985 and no bash versions released after that exists.
It would be nice for those of us not in the know to see an example of more-or-less similar configuration expressed in the respective systems for comparison. Although I tend philosophically towards the declarative route, I don't really have a good understanding of the issues involved in this specific instance - but I'd like to.
Something's wrong with this thread. Being for or against systemd is one thing. Bashing the people who are ready to do some hard work to bring more choices to the table is another.
If someone wants to write another Ruby (or whatever programming language) implementation, would you bash her/him ? Would you say "leave me alone, I'm very happy with MRI" ?
- I think they're wrong about systemd, but if they're right, Debian can merge their fork back in, they can say "I told you so", and we can move on.
- It gives us a place to point the anti-systemd people. Rather than spending their energy trying to fight the system, they can spend their energy productively on this fork.
- This puts the burden of maintaining the SysV scripts on the fork, rather than the package maintainers, as it would be for Ian Jackson's proposal to maintain freedom of choice[1] Maintaining the scripts probably isn't hard for most; testing them probably would be. It would require maintainers to keep a SysV init system up and running on their machines.
Exactly; this reminds me of the quote "I do not agree with what you have to say, but I'll defend to the death your right to say it." A key axiom of free software is that if you don't like something, you can fork it. If your fork is better, it will win (in theory).
It isn't necessarily an efficient allocation of resources, but open-source does not seek to achieve that: it values choice instead.
Sure, feel free to fork Debian. Just don't call your fork Debian or "Pure Debian" or anything silly like that. Debian is a registered trademark of Software in the Public Interest, Inc., and as we saw with the Standard Markdown debacle, people do not like when names of established stuff is hijacked.
Looks like the Squeeze LTS project[1] could use some help[2] and the team proposing a fork are server type folk reading between the lines. Good fit of skill sets and a way of generating positive outcomes quickly to build confidence? So fork from squeeze forward updating strategic packages?
PS: I love the 'how long are your beards?' line. Obviously, I'd rather Debian didn't fork and that we kept choice for server people in one of the larger Linux distros just on an 'ecological diversity' basis.
You can do a window manager on top of X with systemv right now in Jessie [3], the '--no-install-recommends' option to apt-get is helpful. But the result will be seriously old-school. Its rather fun for surfing in cafes and wasting time on forums but for my day to day work (not programming) I prefer a full fat desktop like KDE/Gnome.
As much as I dislike the idea of systemd, I'm starting to think it's pointless to fight it. There's still a large chunk of people that think the desktop is important for Linux's future and will keep pushing for turning it into a brittle mess of opaque components, unaware of what's really important to maintain and troubleshoot servers on a daily basis, and unaware of what has made Linux so successful in this area.
It may happen that systemd ends up being a good thing, or it may happen that something else takes the place that Debian and Red Hat currently occupy in the server space. That thing may very well be something other than Linux, and I don't care if it is anymore.
SysV init is brittle only for desktop scenarios, where many things can change between reboots. On servers I've always found it to be very predictable. Once you fix an issue, it usually stays fixed. I haven't ran into many startup race conditions in servers.
SysV init has many problems and can be improved upon, but solutions that increase complexity exponentially and are impossible to reason about when problems arise aren't the solution.
It worries me to see people justifying increased complexity pretenfing it matters for servers. Two examples:
1. I don't care how long my servers take to boot, that doesn't happen very often and when it does, who cares about cutting 30 seconds on the operating system side when the POST itself takes twice as long?
2. I don't care about too much hardware detection magic. Once a server is installed, at most it will get a memory upgrade sometime along the way, and replacement disks coming in and out of it will be transparently handled by the RAID controller. Most often it will just get scrapped in the exact same configuration it had on day one.
The systemd approach is not unlike the Windows approach. I've managed Windows servers for may years and I've also had to deal with at least an order of magnitude more boot issues that with SysV-like init systems.
How many things can really change between reboots on desktop? That i yank one GPU and install another? VGA is still VGA as a fallback, no?
Frankly the only bus i can see being much of a issue on desktop is USB. And that is mostly if you are relying on a ethernet dongle or similar that ended up moving from port 1 to port 2 between boots.
Yes, this means your desktop may not get connection until you sort out the new name of the port. But that is a niggle, not a world ending scenario that require the full replacement of everything between the kernel and the desktop environment.
All in all, systemd looks like a solution in search of a problem. And if it has remained Poettering's personal project and distro variant i don't think many would have raised a stink (and those that found it interesting would have adopted it on their own time).
At which point why bother with desktop computing or user customizability or ease of use at all! I mean, who really needed Plug and Play?
Or even multi-user desktops. Or removable storage.
In Linux, everything got a lot better when we added udev - which gave us event driven mounts. And then we wrote a bunch of hacks to make sysV init minimally event driven enough to properly wait for it to finish it's work.
systemd simply dispenses with the fiction that SysV init is in anyway actually suitable for bringing up a modern computer, and replaces it with centralization of what we now know are the actual, useful services pretty much all modern computers need to provide. Even embedded systems are likely to be using network mounted and accessible storage.
Can we as a community move on from this? If someone feels like forking a distro "because systemd", let them, and it's only newsworthy if it's successful.
We could also move on from the accusations of "betraying the Unix philosophy". You know what else is the Unix philosophy? User-based security model. Fixed-length strings without overflow checks. World-readable passwords, badly hashed. Unencrypted remote shell with host-based trust. Maybe systemd is good, maybe systemd is bad, but accusing it of merely changing things is not a valid argument.
Debian has always seemed to be about choice. You can even run it (for now, at least) on the FreeBSD kernel if you so choose. Obviously they are going to have to require systemd for Gnome 3.14+, but I see no reason not to allow installing a different init system for people managing headless LAMP servers via SSH, if there is an appropriate amount of developers willing to maintain the necessary packages for this.
Onto debianfork.org ... if history is any indication, naming it Pure Debian is only going to cause a world of pain for everyone. Forkers really need to stop trying to name their projects $superiorAdjective $projectName. That's never going to go over well with $projectName.
And if they do fork Debian, I sure hope they don't set the default UI font to Georgia 40. (I know it adapts to browser width. I don't like setting my browser to 200px width to read a webpage comfortably.)
No. Even the pro-fork advocates (even the above article) see the Jackson / Vernon proposal as a much better idea (choice of init systems with a systemd default)
No. IMHO Debian is less a distro than a democratic experiment - and systemd shows it is working. If you don't like systemd (and I vastly prefer my FreeBSD world) get on board with the democratic process - it is always messy, frustrating, driving you insane slow. That's how you can tell it is working
The person(s) who wrote up this little hissy fit, does not seem able to, nor want to, invest the effort to create and maintain a fork.
"Unless you meet our demands, we shall fork".
More like
"You gotta do what I say, or I am going to scream shout and bang my hands against the wall for a while".
or
"Please someone, fork Debian in the way we want it, and spend your time and energy maintaining it, because we cant be bothered to".
Also, disagreeing with the direction of Debian is not a risky move. Why not sign your names to it? Is this again because you wish to avoid any personal responsibility and work?. If you are well known in the Unix/Linux/Oss community signing your name would give weight to the hissyfit.
The issue is that Gnome, KDE, and other software requires systemd. You need to fix/maintain their compatibility with other init systems. Then it is easy for Debian user to switch init systems.
> The issue is that Gnome, KDE, and other software requires systemd.
This I can't wrap my head around, why does Gnome for example need systemd? There are standard ways on GNU/Linux to do everything it needs in a unix fashion (by deferring to small specialized tools):
shutdown
reboot
whoami
uname
mount
...
These and similar tools (or libc functions) give you all information you need (username, etc.) and system functions a desktop environment needs (reboot, hibernate). You then only need something like udev for plug-and-play (which is available without systemd, and as a part of it), and interfaces to the X/Wayland server and the audio system (which are both not a part of systemd). This seems to be all stuff that can easily be abstracted away in one module per OS. I don't see why you have to tightly couple your DE to systemd. (Unless, you are using your DE as a vehicle to push systemd, which I hope is not the case...)
Systemd provides interfaces to reboot/shutdown as non root api which is controlled by polkit. It also allows a non root process running as part of an active session to get the DRM FD and other device FDs as part of the logind interface.
A bad thing about systemd and where we are now is the ever-changing API that is mentioned, which hampers alternatives to systemd.
But, that is where we are now, Debian isn't in much of a position to change that, and forking probably isn't going to help with that. Debian wasn't ignorant of that either; these issues were discussed at length in the tech committee debate that originally settled on systemd being the default for jessie.
It's big, gnarly, essentially undocumented, and contains a bunch of features to support tricky cases like multiseat machines (systems with two or more sets of keyboard, mouse and monitor, each with a different user) that are rarely used but still need to be supported because the API's designed around them. Even the systemd developers don't think a reimplementation is feasible.
You listed two desktop environments, neither of which are of interest to sysadmins.
Eg. I run an Openstack cluster and do not care if there are gnome or kde packages available. I don't particularly like systemd and would be happier not having to deal with the compatibility and/or conversion issues for what I perceive as minimal benefit.
I'm in a similar position with regard to those (or any) desktop features not being relevant for most of the systems I administer.
I'm kind of irritated about having to learn a whole set of new things. I do recognise that there are some benefits for my use case in systemd. The desktop stuff aren't the only things that systemd brings.
More than that though, is the fact that it's going to be the new default everywhere. So while you say
I don't particularly like systemd and would be happier not having to deal with the compatibility and/or conversion issues for what I perceive as minimal benefit.
I think you (and I) will actually face more work in trying to avoid systemd than convert to it. You'll be fighting against your distribution's default and the default of every bit of third party software targeted at your distro. From what I have seen most conversions are fairly painless.
So from my position that sits somewhere between "ambivalent" and "that's kind of nice", going with the flow seems the easier path.
2) My position is between "that sucks" and "ambivalent"
But I do think that going with the flow is a much easier way. This isn’t a fight worth fighting if your concern is maintaining running systems. Of course it might be worth while to stay on an LTS release till the very last moment, to let all the bugs shake out.
Probably not software like Apache and Postgres, no.
But when systemd is the default init system on almost every Linux distribution, new software will have the systemd integration written first and tested most.
The idea of a server based fork of Debian is kind of appealing in some ways, like the Fedora server and cloud projects[1][2] which are quite interesting work, aimed at a (sub)distribution with focus on particular use cases, not the kitchen sink approach.
I'd be running it on my desktops. All I need is a way to spawn chromium and emacs and consoles (I like konsole, but if it drags in too many dependencies I'll put something else on).
If/When chromium depends on systemd (WTF, a web browser / page renderer logically SHOULD depend on your init system, of course) then I'll use another browser... somehow.
KDE doesn't require systemd. The KDE folks are still concerned about operating on the BSDs. Some of them are still concerned about running on Windows [0] and OS X [1].
Elias Probst:
"Reading the comments shows a lot of misconceptions about +Martin Gräßlin's proposal [to use systemd features to make Plasma startup under Wayland a little bit simpler]:
* KDE SC will still allow to use the old-way to startup a KDE session, as it will still ship the X11-way of doing it for [BSDs]. If you want to use a modern Wayland/systemd stack you're fine by using the defaults. If you don't want to: use the old X11/script startup stack.
* KDE SC won't enforce using systemd as init-system by this change. Instead, it will use parts of systemd which are completely independent from the init-system being used to handle the startup of the KDE session. If systemd is being used as an init-system, that's a plus because of some systemd integration effects, but that's all about it."
So, all I've really heard about Systemd are arguments from proponents and complaints from opponents, and based on that alone it's difficult to get an idea of the true merits of one vs the other because rarely does any one comment lay out all the Pros and Cons for the different init systems.
I am interested in any other comparisons that you believe is a good representation of both sides. I just want to fully understand the two before making a choice.
Edit: Removed references to there only being 2 options, there are multiple init systems.
I know this is just a nitpick, but calling it "SystemD" everywhere on this page when everything written about systemd asks you very nicely to call it "systemd" shows these guys are either not as familiar with systemd as you should probably be if it's that much of an issue for you, or they're deliberately trying to be edgy. Neither of which inspires confidence in their ability to maintain a potential fork.
I am not sure why debian needs to force replace sysvinit, can't they have systemd-debian distro that will have all the shiny stuff in it? and maybe have it grow and if it won't go down with their userbase then they can discontinue it? Everyone moving to systemd seems a bit fishy. C is very insecure for daemon coding with all other options why no use go for example? There might be some influence on behalf interested governmental parties giving a push to systemd. I don't have a problem with systemd its just I think it should have been an option not a default for server setups.
C programs if they are not really carefully coded can be easily hacked by stack smashers, race condition inducers etc.
I am not sure why debian needs to force replace sysvinit, can't they have systemd-debian distro that will have all the shiny stuff in it? and maybe have it grow and if it won't go down with their userbase then they can discontinue it?
Go read the arguments, there are many reasons why they decided to switch. A big part of it is that Gnome/KDE and other upstream software is already dependent on systemd, so keeping SysV means extra effort to fix that.
C is very insecure for daemon coding with all other options why no use go for example?
What do you think the current init system is written in? That's not a reason to keep sysv.
Don't threaten a fork. Just do it when the time comes. It sounds like you don't have a single Debian committer on board and no real influence there so you are going to have to prove yourselves, just like every other vanity distribution.
* These folks seem clueless. The cite Eric Raymond. Enough said.
* I like classic init. I'm actually not a big fan of systemd, but I clearly recognize something needs to be replaced. The system needs to handle parallelism and dependencies. It's essentially the same problem in a hundred different domains (from luigi, to things like make/ant/paver/rake, to things like supervisord). Each systems seems to solve it worse than the one before it.
Personally, I'd actually go with forking make, since it's the one everyone knows and the most Unix-y, modify it to:
Yes. My spidey sense has been tingling about a Debian fork, given the facts mentioned on the link, consistent problems with at least one of Lennart Poettering's previous projects (pulseaudio), and the strong likelihood that politics played a bigger part in the "adoption" of systemd versus technical merit. If the answer from systemd people is that we have no choice but to use systemd, then I hope that a fork happens, and I will contribute a lot to that project, despite the trite downvotes these affirmative comments get.
One thing I struggle with: how does one calibrate one's spidey sense? Reading comments in online forums is likely to bias one towards the people talking the most, which is not a good bet as a representative sample. It's not just systemd; it's any topic of heated discussion. All we hear from on many topics are the people with the strongest emotions. How can we compensate?
If Ritchie and Thompson knew the damage fork-ing would cause to the open source community, they would have never implemented the idea, as a system call in UNIX[1] in 1971.
I don't think that they care(d) much about "the open source community". And why do you think forking causes damage to the open source community? It helps resolve conflicts of interest.
I know they didnt care (there wasnt any significant OS community at the time) and even if they did its not reason to remove a core feature of like fork, because someone might abuse the idea.
It was a kind of pun to state my disaproval to level of fragmentation the linux community has gotten into.
Okay this SystemD saga might or might be AS important as some people tend to think. But fragmenting the community so much and having people working to 10 different, unstable solutions instead of 3 stable ones, its a waste of resources IMHO.
Indeed. Reducing fragmentation is one of the reasons many distribution maintainers liked systemd, since it replaces tons of special snowflake tooling that every distro reimplemented differently with one common upstream (eg. set the hostname, configure binary formats, where to store the OS release name, etc.)
While I agree with the concept of supporting multiple init systems, I don't quite understand why they'd want to fork it out into an entirely different distro.
Isn't it possible to do this with patches, similar to how the linux kernel has RT patches?
There's a whole bunch of debian derivatives out there and veteran unix sysadmins don't necessarily have the skills to deliver this so not sure this is really all that news worthy until they create something.
Apparently 'Veteran Unix Admins' can't even spell systemd right. It not necessarily correlates with their overall knowledge of systemd, but it's still very strange
this whole website rather sounds like a blackmail. I'm not a big fan of systemd (anymore) either. but forking is not a solution to the init-system problem et al.
But I won't be surprised to see them come slinking back in four months with their tails tucked when nobody's actually maintaining any software for the fork.
Just use coreOS and docker on the server and leave the init system discussion to the desktop people.
There are some fundamentally different and sometimes conflicting requirements regarding the startup process on a server and on a desktop machine and I think systemd which is obviously desktop driven will be the catalyst for a split between server and desktop distros.
I don't think classical desktop environments have much future personally, but that's just my gut feeling.
Server will definitely move further into modularization of services, and that will make init systems there less and less interesting.
CoreOS is entirely based on systemd. Fleet is a distributed systemd. It is far more systemd oriented than any other distro, having built it in as a core feature form day one.
.....
> Why don't you do that [i.e. vote against systemd] yourselves?
>
> We are excluded from voting on the issue: only few of us
> have the time and patience to interact with Debian on a
> voluntary basis.
.....
In that case, you don't have the time and patience to operate and maintain a worthwhile and ongoing Debian fork.
In that case, there is no substance to the "question" you're raising, because you wouldn't actually do what you're calling for.
In that case, you're just a handful of guys (or maybe even just one guy) who spent $10 on a domain name... to get more attention for your Slashdot/Reddit/HN post than it otherwise would have had if posted straight to Slashdot/Reddit/HN directly.