I'll be giving it a go right away.
Devuan, the effort to build a systemd-free version of Debian, has released Devuan Jessie 1.0.0, a release candidate felt to be just about the finished article. In a mail sent to the project's followers the self-proclaimed “Veteran Unix Admins” behind Devuan say “This Devuan Jessie release candidate is as close as we can get to …
It's loosing the respect of large projects. The whole point of unixoid operating systems is that they avoid large projects. The largest single project in the GNU/Linux environment, for example is the Linux kernel, and that's heavily guarded. It has to be, because even innocent mistakes can easily corrupt the system. Other projects are usually small and compact with well defined scopes. (Though many GNU projects have broadened those scopes a lot in recent years.)
The idea is that the effort you need to put into software goes up exponentially when you add more lines of code. A 10k project is _much_more_ than 10 times as hard to write and maintain than a 1k project.
The problem we have now is that there is a surplus of people who want to work in "Open Source". Those people want to write code for projects to have something for their resume. Helping on an existing project is easier than starting your own, and huge projects, like systemd, need lots of work. That's why they attract lots of learners and integrate their code. Code written by people in their early years usually sucks. In the past, that code would have gotten into shareware software and would have been erased by the bit rot of the Internet. Now those bad lines of code and those bad design decisions end up in actual Open Source projects which are stored for all eternity on Github.
The result are bugs like this:
> The result are bugs like this:
OMG. And Pottering's response is particularly priceless, too, demonstrating both his ignorance and hubris in one succinct piece of prose: erasing the entire filesystem is "not much of a problem", and "this is a unix problem" (it isn't, as pointed out by multiple other commenters).
I won't go near systemd on the simple basis that I know exactly how good Pottering's previous effort - pulseaudio - isn't. On the basis of having experienced that godawful dreck I'm not letting him anywhere near anything as critical as PID 1.
You very poorly characterise what actually happened.
Immediately after the issue was fixed by someone else, he declares the issue wasn't a problem and demonstrates a profound ignorance of the basic utilities systemd is replacing. Several people then corrected his woefully poor understanding of how rm functions.
If these are "haters" then I'm the fucking pope.
OMG. And Pottering's response is particularly priceless, too, demonstrating both his ignorance and hubris in one succinct piece of prose: erasing the entire filesystem is "not much of a problem", and "this is a unix problem" (it isn't, as pointed out by multiple other commenters).
That is just pure Poettering. As is his reaction to comments pointing out his ignorance:
@poettering poettering locked and limited conversation to collaborators Apr 17, 2017
Each to their own, but I've seen enough that I won't touch any software that has anything to do with Poettering. Kind of like "Once is a chance, twice is coincidence, third time..."
None of my Linux boxen have systemd (yes, I tried it, it can burn in hell). Luckily Centos 6 and Jessie are (or can easily be) systemd free. Looks like its time to give Devuan a try.
Christian Berger wrote
"The result are bugs like this:
Until now I've been just a mildly interested observer of this debate.
However having seen the contributions from the man in question in the bug report in question, I
(a) recommend anyone who hasn't seen them yet has a look at them (it won't take long)
(b) draws their own conclusions (it won't take long)
If any sensible person still thinks that the current incarnation of systemd is a bright idea after reading that, then I'll eat my hat.
(I encourage everyone to read this thread, really, it's not very long)
Based on his response, I can't believe that anyone takes this guy (and systemd) as something that has made it beyond some dead-end fork, let alone in main stream OS's used in servers.
Unbelievable.. The linux distro-world (using systemd) has gone to complete shit.
"Apache is laughing at you right about now."
Since when did Apache turn into a Unix(-like) operating system?
Some larger projects covered by the Apache foundation may target Unix(-like) environments, but that doesn't mean that those Unix(-like) environments are also involved with those Apache projects as well.
O'Really? Here's the current market share *detail* for MS and Apache from https://news.netcraft.com/archives/2017/04/21/april-2017-web-server-survey.html
Share of all sites: Apache 22% MS 44%
Share of active sites: Apache 46% MS 8%
Share of top million busiest sites: Apache 40% MS 10%
Still think "MIcrosoft IIS now has double Apache's market share" is a plausible summary of Netcrafts numbers and charts or even the article text? It is the kind of misleading Twit-sized claim many politicians would happily make, though.
Use the source, readers, always use the source:
"Share of all sites: Apache 22% MS 44%
Still think "MIcrosoft IIS now has double Apache's market share" is a plausible summary of Netcrafts numbers and charts or even the article text? "
Uhm, yes. I'm pretty sure 44 is exactly double 22...
This was always the exact statistic the Apache fans used to quote.
And why Microsoft IIS now has double Apache's market share:
Maybe according to a quick glance at the linked Netcraft page (though I've edited this post to reflect another poster pointed out a better look at the Netcraft site shows otherwise). There's not many places out there that do this sort of work (with a quick check on Google anyway, others can look further if it's important enough to them)
https://w3techs.com/technologies/details/ws-apache/all/all suggests otherwise.
Site hacking must be at an all-time high. When IIS was just a teency little minnow with no defenses to speak of it was vastly more commonly hacked then Apache. Now it's a ugly large monster (still with no defenses to speak of, not like MS know what "security" is or anything) the number of targets out there is so much higher.
(I must wonder who runs Netcraft, and how much of the IIS servers they see are MS spinning up a few million VM's just to fudge the data - but then MS has never been known to falsify data or reports before have they?)
"Site hacking must be at an all-time high. When IIS was just a teency little minnow with no defenses to speak of it was vastly more commonly hacked then Apache"
IIS has always had a far better security record than LAMP stacks, and historically was about 4 time LESS likely to be hacked (allowing for market share at the time). See for instance http://zone-h.org/news/id/4737?zh=1
IIS has always had a far better security record than LAMP stacks,
You'd be a comedian if your deluded trash wasn't on such a serious topic.
Why is it that IIS gets most of the hacks despite being least used? Can't claim something is more secure when it is less widespread but most broken.
How much do they pay you to spread this crap? And how do you go to sleep at night knowing that every time someone takes your advice they're putting their livelihood, and their customer's data at risk? Or are you trying to drum up business for yourself knowing that once people get sick of how broken and insecure MS crap is, you can drop in and sell them a nice secure LAMP system? Or perhaps something based on BSD?
Compared to MS, a house with no windows or doors in the worst neighbourhood is quite secure. (Must be, it has no windows! .. Yeah yeah, I'm outta here... )
See http://zone-h.org/news/id/4737?zh=1 - old - but still true.
We have a consumer protection TV show here in NZ called "Fair Go". It's been around since 1977. Basically they do two things, 1) people can write in with complaints about shoddy businesses or behaviour by people in private deals, and FG chases up the other side and works to either get the victims money back or get a "fair deal" arranged. And they've taken on the big insurance firms, telcos an goverment agencies and won, as well as people trying to rip of their neighbours and so on. And 2) they give people warnings about scams and information on detecting them. One thing they pointed out is a lot of scammers these days are using tricks to hide their true identity. One of them is not having real details in their domain registrations.
Registrant Email: ZONE-H.ORG@domainsbyproxy.com
So that is who you want us to look to for your proof of how good IIS is vs how bad Apache is? Someone organisation who is so trustworthy they use a domain hiding service so you can't find out anything about them?
Your garbage gets worse by the day. That stuff MS is feeding you really is messing up your brain!
"One thing they pointed out is a lot of scammers these days are using tricks to hide their true identity. One of them is not having real details in their domain registrations."
Had it occurred to you that might also be something those associated with website hackers might want to use? A very desperate sounding and failed attempt to cast aspersions...
"Linux gets WAY more hacked when used as an internet facing server."
Zone-h counts website defacements, doesn't it?
Is there a difference between a website defacement and what most people might call a hack?
"More recent stats are actually worse for Linux!"
Then share them please, if you don't mind. Ideally based on something more widely relevant than website defacements. I realise that may be hard work, but you're the one making the claims, you're the one that needs to put up or shut up.
Otherwise people may well just assume it's the same recycled Jeff Jones material you were spouting back in (e.g.) 2013 which itself was based on rather outdated source material.
This Jeff Jones:
Jeff Jones who was claiming in 2007 that, after a whole six months out in the wild, Vista was more secure than Linux and OS-X?
You'd be well advised to quote any more recent references you feel may clarify matters, but in the meantime here's one from 2007, from
or there's this:
Have a lot of fun.
"IIS doesn't tend to be running insecure crap like PHP..."
Case and point. So it's not Linux/Apache versus Windows/IIS security we are talking about per se; what we are really referring to is the plethora of quickly hacked up PHP apps and the like that become low-hanging bot fodder.
Saying that this is a 'Linux' issue is entirely missing the point; it's analogous to the folks that bag 'Java' as insecure without having any clue what they are actually referring to.
Unfortunately I guess this is the price to pay for a platform with such a low entry barrier.
'...now has double Apache's market share...'
If you read the full stats you linked to as opposed to cherry-picking one graph, it shows that Apache comfortably beats IIS in terms of actual use, and nginx is severely eating into the market share of both Apache and IIS. IIS actually shows a long downward trend in most of the graphs that isn't showing any signs of stopping. Take off the rose-tinted glasses and try scrolling down a bit.
"If you read the full stats you linked to as opposed to cherry-picking one graph, it shows that Apache comfortably beats IIS in terms of actual use"
Uhm, no - if you read the article - you will see actual use is 44% IIS to 22% Apache.
This exact statistic is what the Apache fans always used to quote. It's only now that IIS is market leader that you are trying to cherry pick a more limited measure!
This post has been deleted by its author
No, no, no! Use vi as your shell! :-)
From one of my passwd files:
Yes, that's really a user account that I use ... usually on a dumb terminal. I don't like distractions when I'm writing more than throw-away comments, like this one.
Let me guess: your version of vi does not support noob things like arrow keys?
Bonus points for implementing a device that sits between your VT102 keyboard (VT52 acceptable; VT220 is right out) and NOPs the arrow keys using 7400-series ICs and nothing else. Some people have an iron will, but if not it's okay to reinforce your determination with TTL logic and wire-wrap.
I run Slackware. The vi clone is elvis. The arrow keys work ... if the keybr0ad has arrow keys, of course. I rarely find myself reaching for them, though, unless I'm in input mode ;-)
Seriously, try using vi as your shell. You'll be awfully surprised at how functional it is. For test purposes, create a user account with a vi shell. Pull up an xterm & log into that account. See what you can (and cannot) do with vi as your day-to-day CLI shell ... At the very least, you'll learn a lot more about vi than most folks. The concept was suggested to me in jest decades ago (1979ish) when a friend commented that "You seem to live in vi! When was the last time you saw a shell prompt?"
That's a distro issue - ideally the Debian Way would be to have an "Init System" virtual package (is that the right terminology?) that can be fulfilled in several different ways including systemd. But I guess it becomes difficult to do that at such a low level as the init system.
It wasn't difficult before systemd came along. Other inits aren't tied to disparate elements of the OS and don't pile so much functionality into a single package. They just run and manage daemons.
If systemd just ran and managed daemons, there wouldn't be any arguments.
It is a shame that Canonical gave up on 'upstart' as it was almost what was needed: an init process that could handle parallel start-up and dependencies. It could also be run as a user PID if users wanted an event-drives start-stops system, say for removable storage. And there it stopped, as it only wanted to be 'init' and not an octopus.
Plain Debian still allows you to switch to SysV init in a matter of minutes ...
Err, well sort of, but not really.
The problem (as already mentioned) is that SystemD just isn't an init system as it was described as whenever there was any dissent from using it. The problem is that there are so many tentacles that it invades all over the system to the point that you CANNOT uninstall SystemD without breaking an increasing amount of stuff. What you will find if you try it is that you cannot remove all vestiges of SystemD without making your system unusable - such are the gratuitous linkages with bits of SystemD that's enforced by SystemD reinventing established ways of having software interact with other bits of software/the system.
Y'know I STILL hope Devuan withers and dies, the sooner the better ... But the prospect of the Debian project eating some crow and seeing sense seems further away than ever.
So great work guys - I grabbed the relevant downloads last night just before I saw this this morning.
My production box is running Old Stable - so I'll need to upgrade shortly _AND I DON'T WANT SYSTEMD_ so I'll have a serious play with this.
Hopefully, unless things change elsewhere, this project will gain momentum and become the hub of a new distribution ecosytstem (like the way Mint sits/sat on Umbongo which sits on Debian). With so much of the heavy lifting to get this far done the nest release will hopefully follow on next Debian a bit more quickly and the team will be able to take a long look at a few other issues they're bothered about. Including everything pottering is trying to suck into systemd.
Why do you _NOT WANT SYSTEMD_ out of interest? It's an elegant system that works with easily understandable text-based configuration files. It's not a "Registry for Linux" as many articles/posts have claimed, it streamlines bringing up a Linux box and does away with a confusing script-based system that was years out of date and difficult to optimise/parallelise. A change of init system isn't something we should be doing more than once every couple of decades, but systemd seems very good to me.
"A change of init system isn't something we should be doing more than once every couple of decades, but systemd seems very good to me."
The problem is systemd is not JUST an init system, it adds in binary logging, time setting, module loading/blacklisting, and all sorts of other stuff that were pretty much already solved and workable. And in many cases it adds bugs/issues that seemingly just don't get fixed if they are not in line with Pottering's personal outlook.
If it were just a paralleled start-up system there would be far less issues, but instead we have fsking *desktops* like GNOME has become that have systemd as a dependency, WTF?!
"The problem is systemd is not JUST an init system, it adds in binary logging, time setting, module loading/blacklisting, and all sorts of other stuff that were pretty much already solved and workable. And in many cases it adds bugs/issues that seemingly just don't get fixed if they are not in line with Pottering's personal outlook."
I'm sure you've heard the following mantra from the Acolytes:
'The beauty in GPL software is that if you don't like it, you can just grab the code and fix it yourself.'
There. Problem solved. ;-)
'The beauty in GPL software is that if you don't like it, you can just grab the code and fix it yourself.'
Quite so, but generally speaking a user would prefer not to have to fix bugs introduced by twats like Poettering. Fixing accidental bugs, incompatibilities and adding functionality is one thing but having to repair the damage done because somebody working high up wants to dictate how your system should work and doesn't give a flying f*** about complexity, compatibility or usability is something I'd rather not have to do.
Especially when the other big names in Linux have their collective hooters stuffed firmly up Poettering's taskmaster's rear end and will not see reason.
"Why do you _NOT WANT SYSTEMD_ out of interest? It's an elegant system"
It is precisely because it is _not_ an elegant system that I don't use it on my Debian systems. It pokes its nose into all kinds of things it shouldn't. It makes non-standard setups unnecessarily difficult. It facilitates wide-ranging attack exploits by enforcing uniformity everywhere. It makes low level troubleshooting more difficult. Each new version exhibits unpredictable behaviour which makes it risky to use on a remote system. Need I go on?
To be fair, you could describe the unit file configuration system on its own as elegant, but the additional feature creep and complexity rule it out for me.
I had actually dismissed Devuan, but I'm pleased to see they've reached this stage.
I was willing to learn it (I mean, I learned Solaris SMF, which is even more opaque, and I even sort of understand OS X's launchd). But I got very irritated with a number of bugs that no one seemed interested in fixing because they only affected servers, not the desktop machines systemd targets. For example, it became impossible to reboot a machine via ssh if it had automounted NFS shares; it would hang in the shutdown process every time, requiring physical power cycling. Bug reports about this were met with a collective shrug.
Personally I find FreeBSD's init system refreshingly simple.
It's not a "Registry for Linux" as many articles/posts have claimed,
It's something a lot more sinister than a "registry". Something like a registry could be added if one were really needed without everything that systemd is bringing into being.
it streamlines bringing up a Linux box and does away with a confusing script-based system
There was nothing confusing about it. When comparing the various sysvinit machines with my current crop of systemd systems, the way in which systemd is gobbling up various modules and making them difficult, sometimes impossible, to access is, if anything, overcomplicating what was previously trivial to work on.
that was years out of date and difficult to optimise/parallelise.
The age of the system is immaterial if it works. As for optimisation, sysvinit was pretty good where that was concerned and "parallelisation" is merely yet another fad which has little real use.
Having said that, the most recent Devuan beta felt like a bit of a let down when I tried it; even the first beta worked better for me. I'll give it a go with a view to possible future use but it all depends on how well it is set up and, more importantly, how well updating works.
You know what *is* confusing? The new unit files.
Sure, they work. They can build all sorts of dependencies and stuff and you can tell something not to start until something else has started, all that good stuff.
And the old /etc/rc.d/rc?.d/[ks]* symlinks to /etc/rc.d/ scripts also controlled ordering.
Ah, "butt parallelization". Sure. When you're booting a server or a high-end workstation that takes several minutes to enumerate its hardware, you don't care whether the OS boots in 30 seconds or 4 minutes. So systemd's *only good feature* was designed expressly to solve a problem with noddy laptops and other prat-about hardware that's better solved by a decent SSD.
The new unit files ... Sure, they work
I had to write some systemd unit files the other week. One of them had to start after the DM - lightdm in this case - had started. So I used systemd to control the dependency.
Except that it doesn't work; my unit was started after lightdm had started to come up, not once it was functional. I ended up having to do the synchronisation by hand in a script - so it had the worst of all possible worlds.
SysV is so much simpler...
An elegant init system according to UNIX philosophy is a system that does exactly as little as possible in the simplest and sanest way as to be functional at its intended task.
init should not have an attack surface, it should not handle anything more than necessary - its purpose is to start the rest of processes needed for the system to function. Implementing runlevels, parallel startup, dependencies, and process supervision are potentially sensible additions, that don't raise the footprint very much.
For me, the part that is unforgivable about systemd is that it is invasive. Its very existence is a threat to the fundamental architectural principles of simplicity, isolation, transparency, and modularity that were so central to the success, stability and widespread adoption of UNIX and Linux. We're seeing deep dependencies on systemd in software that should have no reason to be aware of an init system, much less interact with one.
> It's an elegant system that works with easily understandable text-based configuration files
No, it's not elegant, and the config files are no easier to understand than the scripts used previously.
> A change of init system isn't something we should be doing more than once every couple of decades
Agreed, but systemd is not an init system (hint: init is an init system). Systemd is spaghetti architecture - even calling it "architecture" at all is generous, of course.
It's a pity that they weren't able to release in 2015, when it was possible mostly to remove systemd from Debian itself, but it seems they must have been gearing up to understand the way systemd has become a dependency even when you don't use it as an init, exactly the issue Devuan warned about.
I mostly use systemd on Debian servers now, but that's because it's becoming harder not to. It's possible on a server, but you just start hitting little irritants. That demonstrates that systemd is far more than the init it claimed to be replacing. I once swapped MTAs from sendmail to postfix at a company with about 400 users. This was done in the middle of the working day, with no loss of service. That's what the unix way of building blocks for services allows, but choosing to run an alternative init is now what systemd expressly prevents in many use cases. Such a pity that Debian, for one, didn't remain neutral in this.
I'd love Devuan to gain credibility and become a plausible alternative.
Thank you for contributing.
For those who would like to contribute in non-technical ways (eg $$$/£££) is there an easy way to do so?
Personally I'd like to stay with Suse but if there's no easy systemd-free option to do so, I'd like there to be some other options too.
Linux user since RH4...
Yes thanks, I was and am serious, and yes I'll be donating a few pounds/dollars/euros today, and hopefully more to come (times are a bit straitened at the moment).
Reminder, here's why I'm donating, you don't need to be a Linux geek (or much of a geek at all) to understand it, it's two minutes to read, and forever to wonder "why?" and "how?" we got here:
I've been donating few quid monthly since the start of the project, also without immediate plan on using it - I have systemd-infested Arch which, for my use, works well enough. So basically my motivation was not as much "displeasure" with systemd as exactly what Devuan promotes - init freedom, for others and perhaps for me (in the future).
Ok, I'll bite. I've done moderate Linux stuff for many years. I get by fine, but I don't put myself in the sage greybeard class.
I've rather like moving to systemd. I'm not a hard core guru of that either, but I've like having some structured approaches to common unit script patterns. I like it much better than the competing "let's just make the scripts more structured with a layered on meta language" that I was having to learn with Upstart and other distorts variants.
So let's say that systemd solves these problem in a deplorable way, does the anti systemd crowd actually have an alternate solution to some of the problems systemd wanted to solve? Or is it just a party of no?
"Or is it just a party of no?"
In short, no it isn't a party of no just for the sake of it.
A lot of people, including me, dislike and distrust systemd because it does not do what it claims. It is supposed to be an init system but due to creep it has its fingers in a lot of other pies as well. Added to that are the like of a binary logging system which adds complexity and Poeterring's seeming fixation on turning Linux into a Windows clone complete with a Registry. I know that people say that systemd speeds up booting but who needs a quick boot on a server and at what cost? Finally as others here have said systemd turns its back on the Unix mantra "Do one thing and do it well."
Does Gnome "do one thing and do it well"? Of course not, it's a GUI desktop environment, not a single program. Within Gnome there are many different executables that form a (sometimes) coherent and cohesive whole and are developed and maintained as a project, and hopefully each executable within Gnome does follow the Unix philosophy. Systemd is exactly the same - it's a collection of small binaries developed and maintained as a project that can form the next step (after a bootloader and kernel) of a complete operating system. There are pros and cons, but systemd does provide a robust mechanism for that bottom layer of a working system and seems to me a far better approach than a collection of shell scripts.
> Does Gnome "do one thing and do it well"?
Gnome is amongst the worst examples you could possibly have picked, given that it's another project that's continually criticised (generally for dumbing down and removing useful features).
It's also a Desktop Environment, so it's kind of expected that it'll contain a wide variety of binaries (just as XFCE, KDE and other DE's do). It's still largely focused on one area though - being a Desktop Environment.
Systemd was supposed to be init, but the wider project has now pulled in other things too (ranging from udev to network management). Technically those other area's aren't part of the init process (in that they're not in PID 1) but they are now part of systemd, leading to systemd increasingly becoming a dependancy for other packages which shouldn't otherwise require systemd specifically.
I have days where I outright hate SystemD, and I have days where I'm ambivalent about it. Can't say I've ever felt good about SystemD though (though the same is probably true for SysV). JournalD and FirewallD though, can die in a fire.
"Does Gnome "do one thing and do it well"?
Nope, and I don't use it either. I even gave up on XFCE and switched to something simpler than that.
Gentoo is still init-system agnostic, and you are free to pick openrc, systemd, or whatever other init system people care to package.
I find systemd annoying when I have to do anything with Ubuntu, CentOS, Suse, etc. But, I haven't really report any problem with it -- all of my daily-use machines use openrc.
"it's a collection of small binaries developed and maintained as a project that can form the next step (after a bootloader and kernel) of a complete operating system."
There were already binaries doing those jobs and doing them well. One of the key things about them was that although they worked together they had well defined boundaries and interfaces between themselves. They did not need to be replaced by an interdependent mess.
One statement made early in the invasion concerned the new systemdified udev. It could be run without systemd but it couldn't be compiled without it. WHAT?????!!!!! This shower couldn't - or wouldn't - structure their code so that common libraries went into one or more source files and the individual programs could be compiled against those without needing to delve into each other's code. Were they really that ignorant of good practice or were they deliberately flouting it? I don't know and frankly I don't care; to know was enough.
This post has been deleted by its author
"Gnome does follow the Unix philosophy. Systemd is exactly the same - it's a collection of small binaries developed and maintained as a project"
This is the kind of sophistry I'd expect from a politician or marketing person. The whole point of the traditional Unix approach is that any components you don't like can be removed and replaced by something else. This is the opposite of the systemd approach. Please don't insult people's intelligence by pretending otherwise.
Anything which doesn't require a custom script for each service during the boot process gets my vote.
Upstart, systemd or anything. I can't remember if Upstart can monitor processes or not, but that's something the init system should be able to do that sysvinit can't ( without a bodge like Monit ).
Um. Monitoring processes is exactly what SysVinit does, but it requires you to actually have processes directly created by init that stick around.
Look at the entries in /etc/inittab. See field 3 in each line, the one that says wait, once or respawn. Respawn allows you to have a service that will be re-stared if the process dies.
What you are referring to as SysVinit is actually the /etc/rc script that is called from init on runlevel change, that runs the scripts from /etc/rc.d (although different SysV UNIX ports actually implement it slightly differently). While this is part of the init suite, it is not init itself.
The concept of init in UNIX goes back to before SysV. I have a copy of the Lyons Edition 6 commentary, and that references an init process, although I think that the /etc/inittab file did not exist at that time. I will fire up my Nordier Intel port of Edition 7 VM at some point to refresh my memory about how Edition 7 started the initial processes.
The rc.d directory heirarchy of scripts appeared at some point between SVR2 and SVR3 IIRC. The first UNIX I remember seeing it in was R&D UNIX 5.2.6 (which was an internal AT&T release).
Back on my own machine. V7x86 partition fired up.
/etc/init is a binary that is run from inside main.c, and it is crafted as process 1 (the source refers to process 0 as being the scheduler, and is just a loop that sleeps on a timer interrupt, and presumably inspects the process table to schedule the other processes).
The source for the Edition 7 init is very simple. It handles single and multi-user modes, and runs /etc/rc, and also handles respawning the getty processes (controlled by the entries in /etc/ttys) as they are used by users logging on and off. It's written as an infinite loop with a wait in it. The wait will return every time a process terminates. It then puts a record in utmp, and if the process was a getty or whatever getty exec'd, it respawns the getty.
Other than that, it does very little. The processes that run at boot are actually started by the /etc/rc script, and that is a simple top-to- bottom script that mounts the other filesystems, starts cron and the update process that periodically.
So much more simple that the SysVinit that implements inittab. I don't have access to any Bell Labs or AT&T source later than Edition 7, although I guess I could look at BSD, but that may not give any insight to when the full-blown SysVinit appeared.
I believe that the Edition 8 source may now be at TUHS (at www.tuhs.org). I must check it out, although this is only related to SysV through the common ancestor of Edition 7.
BTW, Correction to my previous post. Lions is spelt Lions, not Lyons.
I've just looked at TUHS, and if you're interested in UNIX source code, there's lots of interesting stuff has appeared there recently.
Not just source for Edition 8, but Editions 9 and 10 as well.
The biggest revelation I had was when I found the source for something called pdp11v, which is also called PDP-11 3+2.
Have a look, and work out what it is yourself! Remember, even large PDP-11s were really rather small (maximum 4MB memory, small 16KB memory segments, maximum of 128KB text and data size for single processes without some fancy overlaying), so someone having got this running was a real feat.
"I can't remember if Upstart can monitor processes or not, but that's something the init system should be able to do that sysvinit can't"
If a major service goes down I'd want to know why in case trying to bring it up could do something nasty - nasty as in corrupt or destroy data. An init running round like a hyperactive child trying to restart it would be the last thing I'd need. Init needs to start stuff up at boot time and then restart or stop stuff when it's told to and otherwise keep out of the way.
"If a major service goes down I'd want to know why in case trying to bring it up could do something nasty - nasty as in corrupt or destroy data."
But what if you're pressed on the other side of the coin: It's a "five nine's" service that's gone down, and because it's a holiday or whatever, no one's around to verify its state if it goes down, so you're caught in a dilemma. You need it back up ASAP because it costs you real money otherwise, yet you can't trust the environment to be sound enough to send back up.
It's a "five nine's" service that's gone down, and because it's a holiday or whatever, no one's around to verify its state if it goes down, so you're caught in a dilemma. You need it back up ASAP because it costs you real money otherwise,
If you're putting five nines before everything else you're worshipping at the wrong altar. Consider the following:
Maintaining integrity of the data you've got.
Being sure that new data gets added properly.
Being available to add new data.
Availability is a poor third there. Of course five nines availability is something manglement is able to understand and get fixated on. But if you have a big data loss you'll probably lose your five nines whilst you recover it and if you don't recover it all your five nines during the time you were acquiring it turn out to have been a bit pointless. I'm sure there are a few people round KCL who could give you chapter and verse on that.
TL;DR Five nines is nice to have, no more than that.
> But what if you're pressed on the other side of the coin: It's a "five nine's" service that's gone down, and because it's a holiday or whatever, no one's around to verify its state if it goes down,
So you've got a service you're advertising as five nines, but haven't provisioned for appropriate monitoring coverage out of hours?
Your problem there isn't your init system, it's your failure of planning to properly support the service you're offering. As other have said, if the component that went down is brought back up automatically, it could lead to data corruption - so you really want someone to verify things before simply sticking back in service.
If it's a 'five nines' service, then more than one of the same service exists either as a cluster, an active failover, or a DR site. In the case of failure the backup automatically takes over and someone is notified.
If the primary service falls over for an unknown reason, bringing it back up automatically is almost always the wrong thing to do.
if it's a five nines service it isn't running on one single server, and so if one instance goes down it's better it stays down till it can be fixed and brought back up cleanly than it come back up in an indeterminate state and potentially serve corrupt data to your customers, potentially costing you far more than the cost of offering no service for a time. As to "and because it's a holiday or whatever, no one's around to verify its state if it goes down" that's what monitoring and call out rota's are for.
(and if it is a five nines service running on a single server, it won't stay that way for long)
But what if you're pressed on the other side of the coin: It's a "five nine's" service that's gone down, and because it's a holiday or whatever, no one's around to verify its state if it goes down, so you're caught in a dilemma
SysV always gave you a very simple way of causing services to respawn if you wanted them to. Systemd has not solved any problems in that area.
 Or any other, AFAICT...
Ten years and more ago booting a machine faster was a useful thing. But even a raspberryPi zero is up and running without systemd by the time you've hung your jacket on the back of the chair and cleared the shit off your desk.
There is no problem for systemd to solve anymore.
Boot time was a little bit of flash that was thrown into the discussion to make it an easier sell among enthusiasts - I remember it being a thing with the Arch community in particular when systemd was first adopted in late 2012.
The thing is, everything has since got slower; a good example is Fedora, which now has an exceedingly long boot time on a mechanical disk, well in excess of 40 seconds, so we're right back to pre-systemd territory as guess what maintainers get lazy, throw a load of unit files at systemd in the belief it will sort them out.
"Fedora, which now has an exceedingly long boot time on a mechanical disk, well in excess of 40 seconds" with systemd.
Jeez, well if 40 seconds is "exceedingly long" you already have other problems. We're running RHEL7 (with systemd baked in) on server and high-end workstation hardware that takes in excess of 4 minutes to decide who it is, why it's been put on this Good Green Earth, also where its arse is. That's before the kernel loads the ramdisk.
systemd doesn't solve any problems for us, but it brings plenty of new ones.
"does the anti systemd crowd actually have an alternate solution to some of the problems systemd wanted to solve?"
The alternative already exists: stop trying to prevent people from using things that were already working for them. Not everyone has a problem with the things systemd was intended to "solve".
Pulseaudio is now required for audio on Firefox; they've removed support for ALSA and jack.
Palemoon removes the requirement for Firefox. So does Edge but using Edge is like inserting rusty razor blades into your knob before you take a leak. And pouring concentrated lemon juice on it.
I was neutral about SystemD to start with. But then I started hitting issues with it that I never had with previous init systems. Logging is one issue, and the fact it has it's fingers in way too many other areas bothers me. But stability has taken a nose dive as well now. I never had this many inconsistent boots under the old system. I am so fed up with it now I am considering moving across to a non systemd OS.
I am fortunate that in my work I deal with pretty much all the major distributions so moving from a deb to an rpm or even a pacman based distro is no hardship at all. The one that is probably going to get my attention though is arch linux with openRC. To avoid issues in future on my desktop I will also probably move to one of the lightweight Desktops such as Xfce... It does feel like a step back a little but I would rather have stable than pretty...
For me an OS is a tool that lets me get my work done nothing more. I am not religious about it at..
I had even considered moving across to one of the BSDs. Under systemd it is not quite as bad as under Windows but boy is it heading in that direction.
> Under systemd it is not quite as bad as under Windows but boy is it heading in that direction.
That's exactly what some people think about systemd, me included.
Another WIndow-sy thing being the heavy-weight Desktops (Gnome and KDE), put one can always take a lighter one (such as Xfce) or even just a plain old window-manager.
> I have had so many random and weird failures with systemd
A favourite at the moment is one of four apparently identical desktops machines, one of which is stuck in the boot process allegedly trying to make a network connection, either before or after connecting to an NFS server. All is fine in recovery mode and it works as expected, but when systemd has full rein, it spits a dummy and won't tell me why. It may be logging loads in its binary database, but if it won't condescend to letting you log in to look, it's no use. This is not progress.
The absolute most dysfunction I've observed from systemd has arisen from the NFS and networking, on two production servers. I think it was because of systemd's knowledge of the network state, or lack whereof, but I am not certain, and there's a couple of old bugzilla #s out there with similar issues. The developers don't give a toss.
It doesn't help that it's very difficult to tell what's going on, even if you can get to the journal.
The developers don't give a toss.
And this is my other reason why I'll never use systemd if I can use something else. To have the principal developer of one of the most critical parts of the running system tell people that faults and failure are either not his problem or not his fault is not acceptable.
Either be professional and support your code, or pick up your projectile toys and go away.
 Look - I can accept that some edge cases are going to be fairly unique. But when there are so many edge-failure cases that the dev refuses to acknowledge, it makes you start to wonder - especially when taking his ignorance about how the rest of the ecosystem works into account..
It may be logging loads in its binary database, but if it won't condescend to letting you log in to look, it's no use
But, but binary logs are TEH GREATEST and are like, you know, PROGRESS! We must have NEW ways of doing things! We can't stick with old, simple, tried and perfect systems! And it's so hard to have stuff that reads log files if it's not binary.. and. and.. PROGRESS! So what if it breaks when one bit gets flipped, it's PROGRESS! Take your old still-readable-with-25%-corruption text logs that are so old skewl and give us TEH NEW and TEH PROGRESS!
(Ok, sounded funnier in my head when I started....)
have a few advantages, if done sensibly (e.g. a combination of the best of, rather than the worst of, both the Windows NT event logger and GUI, and VMS's vintage-1978-and-still-working ERRLOG.SYS and associated analysis tools).
But systemd's implementation of binary error logging seems to come with too much baggage to make it interesting to many people.
binary error logs in principle could have a few advantages, if done sensibly
I can't see any myself. For a start, the database (or however else the log data is stored) could be fairly easily corrupted just by a flipped bit - say a sizeof or pointer gets a bit flipped meaning that a record is given a size of 512 bytes where it should be 1024, that could cause further problems down the line. A pointer to the wrong place for a record of course can also cause issues. It takes more code to cover that.
Years ago I wrote some software that parsed config files for various addons to a package to build the config for an addon I wrote. It was a simple job of reading the text configs line by line for certain keywords, reading the rest of the line when such a keyword was found, formatting the data in a way that my addon wanted, and spitting the new line out to my systems config file (actually the config builder was an addon to an addon I guess..). IIRC I also wrote some stuff to monitor my BBS's mailer or tosser logs for certain errors and if so to run another task based on that (pulling the damaged mail packets out to a temp file and alerting me so I could have a go at manually fixing them or something like that - we're talking some 20 years ago so memory is like a Scottish fog when it comes to that time of my life...).
Once you have the basic concept of reading text files down (in a software sense I mean), monitoring and processing log files is quite easy to automate. And you can do it on a dead system by pulling the logs into a live system if you want. And even with huge amounts of corruption you can read text files easily (though numbers may be a problem - if 1756723ZK245 appears you know something is wrong, but where 18457 appears when it should be 17457 you're far less likely to see the problem). Binary logs would have the same problem, and would be more susceptible to smaller amounts of data corruption (as above with pointers - if a binary log's pointer to the next record is stuffed, so are you. A text log's pointer to the next record means you move your eyes to the next line (or read in a new line). If the system stops entering the new line characters you can look for other keys (eg many log lines start with "[") and use various text processing tools to automatically add a newline for you if you want. A binary system may not be so easily fixed.
Because of the way text logs are written, if the timestamps get corrupted by any means (whether a failed system clock or attempt at tampering or somehow the data coming from whatever function syslog etc use to get the time is giving corrupted data, eg #saf4@:ce instead of "2017 04 25") you can still follow most things in sequence. How would a binary log system handle corrupted time stamps, or something where the system time was significantly changed?
I am not against better logging and better monitoring of logs. Anything that makes most people's jobs easier is a good thing. I am against things that make most peoples jobs harder, or make jobs easier 90% of the time but make them impossibly hard and stressful those few times when things get really messed up. And it seems that systemd not only makes things so much harder when things break, but (reading comments here) is also too often responsible for the breakage.
All is fine in recovery mode and it works as expected, but when systemd has full rein, it spits a dummy and won't tell me why
I have this with my Ubuntu-based mail server - it's about 12 years old and has gone through many, many version updates - mostly without a hitch (currently on 14.04 - it keeps naging me to update to the latest LTS release but I don't dare - and this started out as a physical box that, eventually, got made into a VM..).
The majority of the problems started when Ubuntu went over to systemd. Like the OP, I have to boot the vm in recovery mode (it's a VM, running under KVM) in order to get it to boot correctly - otherwise I just get a blank screen and no ssh daemon.
I have a backup mailserver vm running on FreeBSD 11 but getting my qmail-based stuff to work properly (and the various Apache websites to serve properly) is being a bit of a pain. But, sooner or later, the pain of *not* moving is going to be greater than the pain of moving and I'll be taking a few days to migrate stuff properly.
 And nothing in the binary log either - I suspect that it doesn't even get that far.
> arch linux with openRC. To avoid issues
> in future on my desktop
Manjaro (based on Arch) had (may still have) an openrc spin, and indeed, one based on XFCE. I ran it for a while, because it's easy to install. but systemd is tenacious in making demands, and all kinds of little issues came up, all relating to systemd dependencies, and this with XFCE, which should make few such demands. Can't blame those who ran up the openrc spin, because Devuan's timescale shows how difficult it must be to keep systemd out.
This is where Gentoo shines - if you don't want systemd, or PulseAudio etc you don't have to have them, almost regardless of which packages you install (so long as the software itself doesn't have a hard dependency on systemd or whatever you're trying to avoid.)
Your entire OS and applications are built with the options YOU want, not what someone else thinks is best. It certainly does take a bit of extra time to get a system up and running but for systems you care about it's well worth it in the long run.
I'm happy to see Devuan making this release and I hope they gain some active users - if for no other reason than to give sloppy application developers less excuse for depending needlessly on systemd or related tentacles.
From the point of view of an end user does systemd or sys V init make any difference or is it just something for those totally unhelpful twits on the forums to argue about. Most end users are not interested in compiling anything, in fact many get upset with the process of installing a program and its dependencies, they just want to use what is before them.
Linux will never be the universal OS as long as these arguments continue and it is difficult for the average user to install and manage what they want to use. It will be seen as the OS of those that want to be superior to everyone, the fact it is used on servers and in the data centre only reinforces that view.
Before you hack me to pieces, I am just an engineer sitting on the sideline trying to make sense of these exotic arguments, also I use OS/2 as my main OS.
I would have been quite happy with systemd on my desktop if it didn't break stuff. Servers are a different matter. For instance on my Desktop I use Mint, on servers it is mostly Debian or Centos.
So I am not tied to any particular distro. I have no principled view on what should be used or how it should work. I am not adverse to change.
My problems with systemd started when my desktop stopped booting into a consistent state. Tracking down the problem was hard because of binary logging, having to futz about to get normal logging working was just an inconvenience. However the fact that I was having to problem solve a boot process for the first time ever was shocking for me. I have never in the last 20 years had to problem solve the boot process in linux. That is my problem with systemd. It is not just an init system, it has it's hooks into other stuff and creates dependencies that weren't there before.
If systemd had simply worked like the old init system did and hadn't created any problems for me I wouldn't be posting here.
I think the "universal OS" trope is the whole problem, actually. Servers and desktops have very different needs and we shouldn't expect to run the same distribution on both. Things like systemd and Network Manager that are added for desktop convenience cause serious problems when they're shoehorned onto servers.
> Things like systemd and Network Manager that are added for desktop convenience [...]
Seems more like "laptop" convenience. My desktop doesn't need dynamic <anything>, as it pretty much the same daemon and network configuration as when it was first set up, months ago.
Not really. A desktop has to work with much more varied hardware configurations including consumer-designed graphics cards with GPUs and 3D demands as well as things like hot-plugging USB hardware of all shapes and sizes from media devices to display adapters (and a good chunk of which are black-boxed, too), in mobile settings where people may be switching from access point to access point, maybe even using LTE modems and so on.
As they say, the devil is in the details. There's a world of difference between making a fixed-hardware interface-light server work and making a desktop that could have any number of things attached to it work.
As I pointed out below, this was exactly what udev was built to handle. It had issues, but it was far superior to the prior solutions. It worked. it just needed to be made more robust.
Instead, Poettering and Sievers decided that udev should be rolled into systemd and made some argument about the init having to know about hardware changes to justify the change. The init doesn't need to know this. Not this intimately. udev, formerly a "do one thing" project, became locked into the "do lots of things" project and has been steadily locked down and crippled to fit the vision of systemd - and of course, in the process, it has forced a dependency on systemd in a wide number of subsystems that formerly only had a dependency on udev.
Things like systemd and Network Manager that are added for desktop convenience cause serious problems when they're shoehorned onto servers.
NetworkManager should be burned on a stake. Twice. Then nuked from orbit. It has absolutely no place on a server. For some reason CentOS insists on it and you have to waste time kicking it back under the rock it crawled from.
"From the point of view of an end user does systemd or sys V init make any difference or is it just something for those totally unhelpful twits on the forums to argue about."
If you read some of the comments on this thread (ignoring the obviously shouty ones) and follow the links to systemd bugs it should be fairly obvious that there are serious problems. As an end user you presumably use web sites. If web site administrators can't keep their systems running reliably due to obscure faults it will affect you as an end user.
"I am just an engineer sitting on the sideline trying to make sense of these exotic arguments"
As an engineer I wouldn't expect you to have much difficulty with that.
> Most end users are not interested ...
Not helpful, I am not "most end users".
When it comes to computers I am a raging fascist pig: the thing has to do what I want it to do and I VERY much want control over it. That said, I refuse to use a piece of software written by some know-it-all that reduces my control for doing the most important things next to the O/S kernel.
Funny how I never ever witnessed failure to reach a consistent state after booting right until systemd entered the picture. That failure alone disqualifies systemd for me.
Just mentioned for context: this isn't for me because I stopped using Linux a long time ago, slowly turned into a veteran FreeBSD user.
But that doesn't mean I can't appreciate and admire all the work and effort which must have gone into this. I love it! I read so many (bad) stories about systemd and having my roots fully tied into Unix as well as the Unix philosophy I don't think it should come as a surprise that I dislike systemd as well, even out on principle alone. In my opinion systemd is better described as usurpd, because that's all it does.
So yeah, I really admire the effort that must have gone into this and I really hope they can keep it up. Let the community decide what they want. And pardon me for laughing it up when it turns out that this will become more popular than other systemd affected environments ;)
I'm running Ubuntu under systemd and can't tell the difference. From what I have managed to glean online the main objections to systemd is that it performs functions that used be done elsewhere. And when problems are discovered (systemd and dbus) the answer from the lead systemd developer (Poettering) is that - it isn't our problem.
the answer from the lead systemd developer (Poettering) is that - it isn't our problem.
And that's one of the biggest reasons why Poettering is mistrusted here. He acts like his word is law, as though he was the second coming of Linus. Systemd is not a replacement for init in his eyes, he wants it to eventually become a replacement for Linux in general, and not only does he have the trust of Redhat, but all the major distros are following him too. I killed off openSUSE on my latest box because it relies too heavily of systemd and Poettering's shite but though I've moved to Mint, I can see the creep going on there too. At least one of the mainstream distros needs to put him in his place but none of them have the balls to do it. If it takes something like Devuan, then more power to them!
I'm running Ubuntu under systemd and can't tell the difference
And that's fine; No it really is, But its not the issue at stake. Some of us HAVE had issues with systemd. And when we find that we want to take it off our machines WE CAN'T; And that is why all the hate.
Just because you can't see or understand the issues with systemd on your laptop doesn't mean that Me with ~500 machines to take care of, if forced to use that festering pile of shit! but ripping systemd out of many modern distros is a fraught and painful experience (I suspect by design)
Forget arguments about it's design, forget ease of use arguments, forget stability arguments... It's about the choice of using or or not; And I get VERY grumpy when people try to ram shit down my throat.
I'm a long time (since versione 3) Debian user, and now I have both Debian Jessie (with systemd removed) and Devuan Jessie beta installed in about 50 servers total. They both work fine. On my desktop I use Mint. I will end up using systemd on my dekstop distro, I suppose, and I can live with it as long as it does not crash too often. But I don't want it in my server.
Last I checked, Devuan repos were missing a number of packages Debian repos weren't and it's still unclear what exactly, if anything, Devuan offers that Debian with systemd removed wouldn't do.
Unless someone can explain what specifically the advantage is, seems like Debian with SysV and OpenRC is still preferable to dabbling in Devuan.
You CANNOT fully remove SystemD from Debian - that is just a myth.
AT THE MOMENT it is near enough possible to get rid of all the functional bits of SystemD, but as time goes on, SystemD spreads it's tentacles into more and more packages.
Basically, SystemD re-implements many previously standard and well understood interfaces. Logging ? Syslog or one of it's modern replacements). Time ? NTP. And so it goes on.
The SystemD camp keep deprecating these standard interfaces - so that packages increasingly over time have to use the "new 'improved'" interfaces or they can't run properly on SystemD systems. Once they do that, then they won't run on systems without those interfaces - ie they won't run without SystemD.
And because Debian (through a very flawed vote process that actually didn't support it) chose to make SystemD the default - any bugs along the lines of "doesn't work properly without SystemD" are just closed as "won't fix".
What Devuan does is take all the Debian base stuff, and fix all those gratuitous dependencies on SystemD. The vast majority of packages are just taken direct from the Debian repositories - the Devuan specific ones are the ones with the crap removed. The expectation is that over time, unless Debian sees sense, that Debian will slowly diverge from Devuan as it allows the SystemD crap to spread.
"The expectation is that over time, unless Debian sees sense, that Debian will slowly diverge from Devuan as it allows the SystemD crap to spread."
My fear is that as the crap spreads it will become impossible to build a Linux system without it. I hope this fear is misplaced.
I dumped GNOME a few years back and switched to MATE. SystemD unnerves me for reasons discussed but the old way is, to be honest, a bit clunky for the 21st century.
First, has MATE had the sense to steer clear of SystemD as a dependency?
Second, and please don't blow my head off, it's just an idea, is it practicable to fork SystemD and castrate its excesses to create a genuinely clean init subsystem?
"Second, and please don't blow my head off, it's just an idea, is it practicable to fork SystemD and castrate its excesses to create a genuinely clean init subsystem?"
I think for many your last suggestion is the nail in systemd's coffin. The group centered around the development of systemd appears insular and opinionated. If it weren't for the "my way or the highway" attitude existing there (and since it's coming mostly from up top, there's no real way to control it), we might see support for paring things down.
Because there ARE things that could use addressing, like better support for dynamic hardware configurations and especially hot-plugging (not prevalent in servers, yes, but essential for end-user stuff).
There's also debate about the very core of the UNIX philosophy because "doing one thing" doesn't guarantee they'll do it RIGHT or CONSISTENTLY, and you need both in order to ensure the stable interrelationship that is essential to make a process chain work. Interdependency chains create "weak link" problems that aren't always obvious. Nothing fouls up a maintainers day like one of those "one things" going WRONG, messing up the process chain, and then mangling the logs and backtraces to make backtracking difficult. It doesn't help that there's no real manual of style for scripting or configuration files, so each one does things differently leading to more inconsistency. From my perspective, the whole problem is something that's neither here or there: in other words, it's complicated, and there's no real ability to debate over the best way to approach this due to the spate of extremists in the discussion (see the systemd problem above).
Probably because it wasn't intended to be an actual fork but rather a demonstration on just how tightly integrated the systemd components are. Sort of a, "Oh, you say it's so simple?" response to claims that you can separate the components.
As I've mentioned, the desire to have this kind of integration appears to come from up top, meaning any attempt to divorce the init part of systemd from the rest is unlikely and it would make more sense to start from scratch. Trouble is, something as serious as an init replacement, especially for modern environments, will likely need some backing, and most commercial interests that back Linux projects are backing systemd.
> Let's not forget that the commercial interest that most strongly backs systemd also maintains the systemd-free RH6. Hmmmm.
That's only because systemd wasn't an option at RHEL6 release, and RH avoid breaking binary compatibility for point releases. Otherwise their enterprise customers would throw a fit.
It's in RHEL7 & 8 though, so anyone sticking to that company's products will probably need to get used to it.
"First, has MATE had the sense to steer clear of SystemD as a dependency?"
Above has a discussion and links to other resources including the Arch wiki and to Gentoo documentation.
link above lists the installation instructions for a range of Linux/*BSD distributions.
It looks as if the answer to your entirely reasonable question is "it depends on which options in the .config file the packager decided to enable"
That's quite all right but I was under the impression that all orbits are swooshes. That page refers to orbit repeatedly and calls it a swish instead but that really doesn't matter-- it might as well be called a Comic Sans. I would have probably made a huge fuss over just turning the 'U' on its side to make the 'D' so it's probably just as well nobody asked me :D
I'm puzzled by people that raise the bogey man of "binary logging"
It's really not _that_ hard to discover that the command 'journalctl' will spew out the contents of those log files, as text, with the added bonus of having the opportunity to add options that give you the logs from this boot, or any previous boot, or only logs associated with particular binaries or services (if you can work out the not very memorable options required).
You can pipe that into the grep command that you were going to point at your logs, and get the same result, with the added bonus that you don't have to guess the right log file, or wonder if some of the messages you were looking for went elsewhere, or decompress the older compressed (and hence binary) logs, and then sod about stitching them back together with cat if you want to grep back across several of those log files.
Not that any of that's particularly relevant to Debian, which still defaults to running rsyslogd, with its normal text files, and will only do binary logging if you choose to create the /var/log/journal/ directory.
The problem comes when you don't have access to journalctl. Say you're booting from an external device because the original drive no longer boots (or worse, you transplanted the drive to another system). Odds are, the journal's mangled and the recovery system you're using doesn't grok the binary log. It's somewhat easier to make at least some sense of a mangled ASCII file; it's one time where INefficiency is a boon (more room for error). As for filtering, as long as the log's well-formatted, you can simply run an ASCII log through the usual trove of text-selector utilities like grep to winnow things down. You'll have to demonstrate (very useful) things that simply cannot be done any way OTHER than a binary log.
"It's really not _that_ hard to discover that the command 'journalctl' will spew out the contents of those log files, as text, with the added bonus of having the opportunity to add options that give you the logs from this boot"
One of the times when you really need to see logs is when the sodding thing won't boot cleanly. At least with a text log you can take the disk out and mount it on something else to see if you've got anything.
But basically, a binary log is hiding things from me. I have to trust the folk who are hiding things from me to grant me a view of what they're hiding. And I have a fundamental distrust of people who hide things.
"I'm puzzled by people that raise the bogey man of "binary logging""
Next time you have to mount a drive from an unbootable system in another (possibly non-systemd) system to read the logs your puzzlement may disappear.
"Not that any of that's particularly relevant to Debian, which still defaults to running rsyslogd, with its normal text files"
AFAIK (and corrections welcome if I'm wrong) binary logging can't be turned off, only masked or redirected to /dev/null. On a heavily loaded system having two sets of logs running could have a significant performance impact.
'm puzzled by people that raise the bogey man of "binary logging"
Are the log files still accessible if something has corrupted oh, lets say 1% of the log? And as Charles points out, if journalctl isn't functional/accessible?
Can you do stuff like grep+tail and so forth?
Text is such a basic system. Quick and easy to parse (your grep example means I have to learn and remember extra commands just to see what I can see easily normally). All systemd does is takes a basic, simple, and functional system and turns it into a complex pile of rubbish that will be unusable when you really need it. I doubt that any of the examples of "problems" you claim it solves (eg "with the added bonus of having the opportunity to add options that give you the logs from this boot, or any previous boot, or only logs associated with particular binaries or services") really exist for anyone - I can quickly and easily find the logs for the services I want and should they not have a log file of their own (on my systems stuff that seldom really matters gets one place, anything I wish to keep separate gets its own log file), and just the timestamp on a log file can tell me a lot. This crap doesn't solve any problems, doesn't make any tasks easier, and just ads complex junk that'll lead to problems. We need to be rid of systemd ASAP.
> I'm puzzled by people that raise the bogey man of "binary logging"
I'm puzzled that anyone thought binary logging was of any use whatsoever. Saying it's not a problem because you can fix it with yet another piece of otherwise unnecessary baggage is rather unhelpful.
Future History Of Init Systems
2015: systemd becomes default boot manager in debian.
2017: "complete, from-scratch rewrite". In order to not have to maintain backwards compatibility, project is renamed to system-e.
2019: debut of systemf, absorbtion of other projects including alsa, pulseaudio, xorg, GTK, and opengl.
2021: systemg maintainers make the controversial decision to absorb The Internet Archive. Systemh created as a fork without Internet Archive.
2022: systemi, a fork of systemf focusing on reliability and minimalism becomes default debian init system.
2028: systemj, a complete, from-scratch rewrite is controversial for trying to reintroduce binary logging. Consensus is against the systemj devs as sysadmins remember the great systemd logging bug of 2017 unkindly. Systemj project is eventually abandoned.
2029: systemk codebase used as basis for a military project to create a strong AI, known as "project skynet". Software behaves paradoxically and project is terminated.
2033: systeml - "system lean" - a "back to basics", from-scratch rewrite, takes off on several server platforms, boasting increased reliability. systemm, "system mean", a fork, used in security-focused distros.
2117: critical bug discovered in the long-abandoned but critical and ubiquitous system-r project. A new project, system-s, is announced to address shortcomings in the hundred-year-old codebase. A from-scratch rewrite begins.
2142: systemu project, based on a derivative of systemk, introduces "Artificially intelligent init system which will shave 0.25 seconds off your boot time and absolutely definitely will not subjugate humanity". Millions die. The survivors declare "thou shalt not make an init system in the likeness of the human mind" as their highest law.
2147: systemv - a collection of shell scripts written around a very simple and reliable PID 1 introduced, based on the brand new religious doctrines of "keep it simple, stupid" and "do one thing, and do it well". People's computers start working properly again, something few living people can remember. Wyld Stallyns release their 94th album. Everybody lives in peace and harmony.
Not every change is for the better. systemd changes a whole bunch of things for absolutely no purpose, to the detriment of users and developers. It isn't any form of progress. This idea that new is always better is a fallacy.
systemd is a regression - a reduction in quality and maintainability. Rejecting regression is a good thing.
You forget. The Amish are technophobes. They're very much against using electricity; computers are essentially taboo to them.
What you probably intend to coin is perhaps "Luddix" on the belief that technology isn't the answer to everything.
PS. Back to the discussion. If we do have to go back to square one, how DO we better handle dynamic hardware configurations where even basic things like displays can come and go on a moment's notice?
"how DO we better handle dynamic hardware configurations where even basic things like displays can come and go on a moment's notice?"
By making a solution that doesn't break things for users who don't require that. Most of the (rational) criticism of systemd is that it makes things unnecessarily difficult for those who don't need it.
By making a solution that doesn't break things for users who don't require that.
*DING* *DING* *DING* *DING*
For my use-case (and yes, I'm aware that that my use-case might not be the same as others, but it's pretty standard - it's a headless server VM with a fixed, unchanging and non-dynamic hardware set), systemd introduces a whole set of cruft and services I DON'T NEED!
At least one of which means that I can't boot the VM in anything other than recovery mode.
Really? Then perhaps you can list and rebut all the objections to it, including boring things like ntp and udev best kept separate, not using an ASCII log that can be read easily even if you're forced to read a crashed drive by raw sectors, and especially the attitude coming from up top of "my way or the highway," and no, Linus is better than Pottering in this regard. Linus objects to stupid stuff. Pottering objects to stuff that isn't his.
djb and Poettering are very different. djb is an exceptionally smart cryptographer that no distro trusts, and Poettering is an exceptionally naive developer that every distro trusts.
The only similarity between the two is that they both have the firmly held belief that they are right; when it comes to security, I'm inclined to trust djb on that regard.
You can have ASCII logging. A simple Google would show you how to set it up, assuming your dist doesn't already. It would also explain the rationale for binary logging (e.g. forward secure sealing, capturing extra information, better indexing, tamper detection etc.).
I have no idea what you mean about ntp and udev being kept separate. Perhaps you're referring to the fact that systemd package contains a lot of low-level commands that you are free to use or not use as your requirements dictate. Systemd provides a SNTP (S for simple) client called timesync. You are completely free to install a full blown client-server ntpd if you desire but many deployments don't need that complexity and a simple NTP client means they can avoid installing ntpd altogether.
But hey, systemd is evillll!!! Let the dance of derp continue.
Anything that involves a translation means things can get LOST in translation, especially if a system is heavily used. START with an ASCII log, THEN work from there on an AUXILIARY basis. Until you can prove yourself able to dig through a mangled journal on a crashed drive using a raw sector editor (because the system you're using for the post-mortem may not even be a Linux machine, so forget about one that groks a binary log to say nothing of an extended filesystem), don't even get started.
Why MUST the log be binary for forward-secure sealing? Why not encode a TEXT log and append the Hex-encoded hash to the log? You get your signature AND maintain an ASCII log that can still be read in the event of a disaster. It's nothing more than a blockchain, and you don't need to use binary formats to create a blockchain.
As for enclosing those utilities, remember the old Microsoft mantra? The three E's? Embrace, Extend, and Extinguish. This seems like a blatant attempt to usurp baseline utilities and take over their control so that no one else can keep up? Look at what happened to udev, which was working pretty well all by itself. Between it and the existing init systems, you'd be well on your way to solving most of the existing problems with dynamic hardware, containerization, and so on while still keeping things distinct.
And what about Bug #5644? In any other circles, this would be a Drop Everything because it breaks a cardinal rule of Linux (Don't allow easy tampering of the root). Here it's a WONTFIX. And not because it's a non-issue, because no real reason is given for ignoring the issue. Where I come from, we call that "taking the ball out of spite" and consider this a sign the project is Not Ready for Prime Time and the head to be blackballed.
Frankly, if they could demonstrate one clear and present need that systemd AND ONLY systemd solves by its particular methodology, we'd probably pay at least some attention to it. But until then...
"You can have ASCII logging. A simple Google would show you how to set it up, assuming your dist doesn't already."
Unfortunately it doesn't tell me how to turn off binary logging, only mask it or redirect it to /dev/null. I don't want the extra processing overhead of generating a redundant set of logging data only to dispose of it.
The problem here isn't that alternatives can't be used, but that a lot of the stuff built into systemd can't be _removed_ .
"Unfortunately it doesn't tell me how to turn off binary logging, only mask it or redirect it to /dev/null. I don't want the extra processing overhead of generating a redundant set of logging data only to dispose of it."
You can turn off the storage in journald by adding Storage=none to the conf file and it logs nothing. Set a flag and it sends the text to someplace else if you like or the console. It isn't as though logging takes much resources in the first place though.
The reality is the binary logs are there so they can be journaled, indexed, tamper resistent, searchable and all the rest. Things that administrators want or should want. It doesn't even stop you extracting the journal as text. It does allow you to tell if somebody has deleted lines from your journal. It does allow you to efficiently search between two date ranges on a particular event.
It's just an example of the knee jerk reactions that people hate on it without bothering to check if supports what they're trying to do.
"You can turn off the storage in journald by adding Storage=none to the conf file and it logs nothing. Set a flag and it sends the text to someplace else if you like or the console. It isn't as though logging takes much resources in the first place though."
I've had a system hang due to journald generating absurd amounts of data. It was fixable, but that's not the point. I don't want that data generated in the first place.
"It's just an example of the knee jerk reactions that people hate on it without bothering to check if supports what they're trying to do."
I don't hate systemd; I'm happy it exists for those who want to use it. I've made what I consider to be a sensible engineering decision to remove it from my own systems. Don't take it personally.
"The reality is the binary logs are there so they can be journaled, indexed, tamper resistent, searchable and all the rest. Things that administrators want or should want. It doesn't even stop you extracting the journal as text. It does allow you to tell if somebody has deleted lines from your journal. It does allow you to efficiently search between two date ranges on a particular event."
EVERYTHING you describe can be done with an all-text journal.
The kernel log can be timestamp and is frequently already timestamped.
If you really need indexing, you can generate an external file. I know video editors that use this technique for interframe videos.
You don't need a binary format to create a blockchain as they tend to be format-agnostic.
And logs are already searchable. Since most log searches are textual in nature, a simple linear search remains the most practical. A text log is easier to perform a textual linear search.
Now tell me how you extract a text journal from a crashed drive when it was housing your only systemd-based system? As Spike Milligan put it, it's like trying to open a box with the crowbar you will find inside.
It isn't as though logging takes much resources in the first place though.
And here is one of the big problems with systemd's development. "We're not willing/to arrogant/to dumn to see how it can be problem to us so why should we bother fixing it?".
I don't care if it uses few resources. If I don't want it turned on then it should be turned off. My lavalamp uses very few resources, but I am quite happy to hit the off switch when I don't want it on. Those "few resources" can add up to quite a bit when enough of it is going on. And the arrogance, ignorance and sheer stupidity that is a problem with systemd and it's is apparent in your post... "It's not our fault/problem, other people don't have a problem with it, so we won't bother with it".
If people want binary logging then let them turn it on. If they don't want it then let them turn it off completely. MS can figure out ways that their extraneous services can be turned off completely, I'm sure that someone even as feeble-minded as a systemd supporter can at least work that much out.
The reality is the binary logs are there so they can be journaled, indexed, tamper resistent, searchable and all the rest.
Are you really that thick? Do you truly believe that these things have not been long fixed? Hang on, lets fire up an old VM and check... "grep -ir mika /var/log/*".. Yup, gets results back. Like it has done since grep was invented (or /var/log, depending on which came last). So we have searchable. Indexed... Is that worthwhile? If so, trivial to build an index file for it then. Strange, I know, but I think you could actually use a computer to index stuff. It might be a whole new concept but.... Journaled.. What problem does this solve? How many problems and how much unnecessary complexity does this create? Tamper-resistant may be nice, but looking at the attitude of that Potty thing at the head of systemd, I would not trust it to work. Charles 9 suggests a quite workable solution to this. How much intrusion detection is done just through logs anyway?
Does systemd actually log anything that would really be relevant when someone is trying to break in or change stuff? Does it log anything over and above what would be logged by a normal system? Again, given the attitudes of the leadership, I doubt it would log anything relevant or helpful. More likely a hindrance. After all just writing a single byte to the log journal in the wrong place would be enough to trash it. Write a single byte to a 5 byte log entry and you can probably still make sense of it.
So why introduce something that is unnecessarily complex and far more susceptible to file corruption? How does it help any one?
capturing extra information,
On a few occasions I've written programs/scripts that have a logging element to them. As the programmer, I decide what and how much is being logged. If I decide that my program will log stuff-all (if anything) then you have little or no chance of seeing this. How can the addition of binary logging change this? How can it change this in a way that cannot be done with other tools? And is the extra information it captures worthwhile information, or is it like the system error logs that "Microsoft Internet Services" so love to point elderly ladies to when they're trying to
steal their money "fix the viruses on their computer internet"? Sometimes "extra information" can be a problem and can lead someone away from a solution.
And when the index gets corrupted at the time of a major failure? You know, when sequential logs are quite important? How would a binary index help anyway? Seriously. I've spent a lot of time with my head buried in piles of logs seeking answers to problems. Either they're there quickly and a glance can see what is going on (eg a web page not displaying, Apache's log shows that there's a permissions problem and I can go in and fix it) or they're something that can require a lot more reading. Being able to scroll down a file is much faster than having to load in a record each time you want to read a new line.
Grep or search functions have been the only "index" I've needed when things go wrong. Well them and Google, but google is for finding answers to why I am seeing the content in the log, not for reading the log. And the content of the logs have always been plenty enough, often excessive. I can't recall a time when I've had insufficient logs to fix a problem (insufficient knowledge, sure, but not insufficient logs!). Caveat : I've not had to fix a lot of Linux stuff, which is a huge reason why I use it and love it.
"no point in trying to rebut all lies and misunderstandings"
Please make the effort to do so, if they are indeed misunderstandings. There are some angry comments here about systemd, but I'd be very interested in your rebuttal of the more rational comments from those of us who have what we believe are sound technical objections to systemd's design.
"Please make the effort to do so, if they are indeed misunderstandings. There are some angry comments here about systemd, but I'd be very interested in your rebuttal of the more rational comments from those of us who have what we believe are sound technical objections to systemd's design."
I think what they're saying is that you can't fix Stupid. And you can't stop people ignoring things they WANT to ignore.
"no point in trying to rebut all lies and misunderstandings"
"might cure some of the ignorance demonstrated here of posters who get the info from other troll posters"
OK, so can we go direct to a reliable source then?
E.g. https://github.com/systemd/systemd/issues/5644 takes a minute or two to read and doesn't require much technical knowledge at all.
Is there much ignorance and misunderstanding apparent there in those few short posts? Where's it coming from?
Me, I'm just a mildly interested bystander. Or I had been, till I saw that github thread. I suspect many others might react the same way.
E.g. https://github.com/systemd/systemd/issues/5644 takes a minute or two to read and doesn't require much technical knowledge at all.Yes? What's to understand? There was a bug. It's fixed.
That some people came charging along to shout about the bug after it was fixed, forcing the locking of the bug report says more about the people who complain about systemd than the people who write it.
"some people came charging along to shout about the bug after it was fixed"
True. The bug itself illustrates the developers' disdain for (and ignorance of) POSIX standards, however. That's enough on its own to make me reluctant to use systemd, regardless of other problems.
no point in trying to rebut all lies and misunderstandings, too many of them. go do some research, might cure some of the ignorance demonstrated here
Yep. Not like there's people here who live and breath Linux/Security etc, who have had to work at rebuilding systems after a failure, and work hard at figuring out what happened in the process (made so much easier with binary logs that are so easy to read with a crashed system! So much better than plain, and so very old, text!). Why, I doubt even one reader on El Reg would have a clue about what Linux is, let alone any of them ever having had experience in development of any sort!
We knew this day was coming.
Want to know where systemd is headed? Take a look at this:
That graph is linked from:
If the 'wontfix' bugs were included, the numbers would be even worse. systemd is sinking under its own weight. May it disappear to the bottom of the ocean of software failures where it belongs!!
"Nice straw man. The few "raging" comments here are outnumbered by comments from those who have had genuine problems with systemd. Got any answers for them?"
No, they're outnumbered by a lot of whining, a handful of anecdotes, a mass of misconceptions and a various statements that are false or distorted. If you have a specific problem, go look up your problem on superuser.com or a similar site because chances are it's already been answered more than adequately.
I've already dealt with a share of issues here - text logging (just configure it), timesync client (a small SNTP client adequate for 95% of uses vs a full blown 20x larger NTP client/server) et al.
It's funny how for all the people whining about systemd Red Hat and other major dists manage to use it without the world collapsing around them.
"No, they're outnumbered by a lot of whining, a handful of anecdotes..."
One person's "anecdote" is another's practical experience.
"If you have a specific problem, go look up your problem on superuser.com or a similar site..."
Some on this forum might consider such advice patronising.
"It's funny how for all the people whining about systemd Red Hat and other major dists manage to use it without the world collapsing around them."
Not funny at all. Those people have made their own decisions about their own systems. I've made mine. I don't see why anyone would have a problem with that.
"Hardware support stinks, especially for end users."
Hardware support for desktop/laptop systems isn't as good as in Linux, but I don't see it being a problem for most servers.
Judging by the number of commenters here who have problems with systemd (who I suspect represent the tip of quite a large iceberg) I expect *BSD use to increase substantially if it becomes impractical to avoid systemd on Linux. That should provide some incentive for better hardware support.
I've used Debian 8 with SYSTEMD installed on it for a while now, and I'll be honest I don't see any sort of improvement. And I mean that. It's like finding a screw in a bag of spanners trying to do things with it.
I held fire on looking at Devuan until I saw more progress with it. I'm glad it's coming along nicely, and it'll be on my laptop over the course of the May Bank Holiday.
We should be given the choice about whether we want systemv (which just works) or systemd (which will soon have a word processor attached to it). Neither should be forced on us.
Patrick Volkerding said in 2012 that Slackware may be forced to use Systemd in the future. Granted, we're 5 years on from that and 14.2 doesn't include it, but that doesn't mean it won't happen.
If Systemd solved a problem and was the obvious better choice compared to Sysvinit then there'd be no issue with adoption. But Systemd doesn't solve any problems, not to any great extent or benefit.
Recently ported a large legacy application suite from 32-bit Linux to 64-bit and a systemd distro.
The systemd bit was the thing that caused the most headaches and pain.
It was never clear what problem systemd was suppose to be solving. The only thing I've seen touted was that it streamlined boot times - when was this a problem? How often are servers rebooted? (Perhaps once a year?)
In fact, it is far more common to *reboot* a system - and in this systemd seemed to be appallingly bad compared to the "old" way. Unravelling dependencies in reverse - either not much thought or effort has been put into this, or no adequate solution has been found. Rebooting went from under a minute to 15+ minutes or "infinity" (power button).
I really wouldn't mind if systemd actually did something useful. But so far it seems like a big steaming pile of regression.
This post has been deleted by a moderator
"Gnuinos, Refracta, Exe GNU/Linux, Nelum-dev1, Star, heads, good-life-linux and Crowz."
The sheer # of obscure distros. I'm wondering how many have essentially 0 regular users outside of the developer(s) themselves. They use the distro to develop the user-less distro. At best many probably have users who install, test, wipe and move on to the next in the distrowatch list, for fun.
Now if we could just get somebody to basically make a Devuan based clone of Linux Mint Cinnamon that would be excellent.
I wonder how much in the way of donations it would take to get the Mint guys interested in a version.
(Because unfortunately with the 18.xx versions they went the way of the systemd darkside).
Yes, thanks to the wonders of modern veterinary medicine the dogs have been sleeping on the same bed as me for years & there has been no insect problems whatsoever.
Tip: If you like having the dogs sleep on the bed with you, get a large square bed, so whatever angle you get pushed into, your head and feet are still on the bed.
Tip: If you like having the dogs sleep on the bed with you, get a large square bed, so whatever angle you get pushed into, your head and feet are still on the bed.
I'm not a dog person but a cat person. Tip : If you like having cats sleep on the bed don't worry about the bed size. A cat will always occupy all but a 2" strip of the bed, that strip being whichever spot is the most uncomfortable right at this time. The smallness of the cat or the largeness of the bed have no effect on this whatsoever.
(Because unfortunately with the 18.xx versions they went the way of the systemd darkside).
Thanks for that. For some reason I thought that 17.x were using it as well and I was planning to migrate away from mint/mate, but now I see I don't yet need to do so. Just need to get rid of puke audio now, which is tied into mate-control-center through a couple of steps.
Or maybe when I get a spare few days I'll gran Devuan and move over. There's a program or two I use often that it doesn't yet have in the repos, but I might be able to grab the .debs anyway and be done with it. So long as they don't list systemd or brokeaudio as dependencies.
Goodness me! All these fractious and argumentative people, abusing the main-stream for no other reason than it is the main-stream. Heaven forbid that one should have to consider the possibility that Mark Shuttleworth was right....
My Devuan-1.0 net-install is running (just like a bought one) as I type wit and wisdom here... or demonstrate my ignorance, both work.... let's see how well Devuan works.
We don't use this box often. It's old, beatup, has no keys, (we use a usb keyboard), and has only 1 gig ram. I still like it. I usually use my old asus board 8 gig ram and Phenom II processor. The 1521 is sort of weird. I guess it was built for windows vista but win 7 runs on it. I think all I needed was the vista video driver and maybe the dell wireless package to run 7 comfortably. winxp was a nightmare. don't remember if I ever got all the drivers for xp.
This box has run a lot of nix's. several *BSD's. I think slackware-current x86 and x86_64 kernel wants too much of it though. The older slacks run fine. devuan 3.16.0-4-686-pae runs smoothly. Could do without the pae as it has so little ram.
Biting the hand that feeds IT © 1998–2020