“I wish systemd would get over its thing about syslog”(utcc.utoronto.ca)
utcc.utoronto.ca
“I wish systemd would get over its thing about syslog”
http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdAndSyslog
9 comments
That's just bad, this is breaking API's ... suddenly other logging deamons need to change their code because systemd is squatting the log file ?!?
SystemD makes me feel weird.
When I boot Debian 8 (which has systemd) I'm amazed how quickly it boots. Systemd units are nice. SysVinit was a mess.
I wish I could interrupt stuck processes when booting / shutting down: http://i.imgur.com/a4ImjAk.jpg
When someone comments about how overly complex and controlling systemd is for an init system, I think of all the hideous shell scripts that don't talk to their neighbors which end up forming most the sysvinit boot process on many distros (in the past?).
I wish there was something [lighter|simpler|more portable|more unix] than systemd.
Every time I seed something [good|bad] about systemd it makes me want to [comment|upvote|walk away].
When I boot Debian 8 (which has systemd) I'm amazed how quickly it boots. Systemd units are nice. SysVinit was a mess.
I wish I could interrupt stuck processes when booting / shutting down: http://i.imgur.com/a4ImjAk.jpg
When someone comments about how overly complex and controlling systemd is for an init system, I think of all the hideous shell scripts that don't talk to their neighbors which end up forming most the sysvinit boot process on many distros (in the past?).
I wish there was something [lighter|simpler|more portable|more unix] than systemd.
Every time I seed something [good|bad] about systemd it makes me want to [comment|upvote|walk away].
> SysVinit was a mess.
Not just SysV - every attempt to move beyond BSD-style init has been a mess.
> I wish there was something [lighter|simpler|more portable|more unix] than systemd.
I think the trick with systemd is to realise that it's not unix. But it's something else that's really interesting in its own right.
Init/scheduling is a much more difficult problem than it first appears, and it has always and everywhere been tacked on to its host OS as an afterthought: init scripts, cron, windows services, system v init. All are poor, partial solutions. Yuck.
To fill the void, there has been a proliferation of application containers, each of which does a different 70% of the general problem. All of this stuff could just be done in the platform. And that's what systemd is.
There's going to be two separate camps at the end of this: a group led by the BSD platforms will stick to convenitional unix goals. On the other side, the linux kernel plays second-fiddle to systemd. The systemd service graph is a new operating system tradition.
[New, but not without precedent: in the debian world, the 'apt' package management system has become more significant than the kernel. You can create things that are not linux, but which are still debian. Both systemd and apt use a sophisticated data-graph to contain a difficult problem.]
There are exciting opportunities for developers on a systemd operating system: you'll be able to quickly put together application stacks using microservices in a way that hasn't been practical until now. It /is/ unixy in the sense that it gives the console operator a powerful new general-purpose tool.
Not just SysV - every attempt to move beyond BSD-style init has been a mess.
> I wish there was something [lighter|simpler|more portable|more unix] than systemd.
I think the trick with systemd is to realise that it's not unix. But it's something else that's really interesting in its own right.
Init/scheduling is a much more difficult problem than it first appears, and it has always and everywhere been tacked on to its host OS as an afterthought: init scripts, cron, windows services, system v init. All are poor, partial solutions. Yuck.
To fill the void, there has been a proliferation of application containers, each of which does a different 70% of the general problem. All of this stuff could just be done in the platform. And that's what systemd is.
There's going to be two separate camps at the end of this: a group led by the BSD platforms will stick to convenitional unix goals. On the other side, the linux kernel plays second-fiddle to systemd. The systemd service graph is a new operating system tradition.
[New, but not without precedent: in the debian world, the 'apt' package management system has become more significant than the kernel. You can create things that are not linux, but which are still debian. Both systemd and apt use a sophisticated data-graph to contain a difficult problem.]
There are exciting opportunities for developers on a systemd operating system: you'll be able to quickly put together application stacks using microservices in a way that hasn't been practical until now. It /is/ unixy in the sense that it gives the console operator a powerful new general-purpose tool.
I think the trick with systemd is to realise that it's not unix.
I keep coming back to that. It seems to me that there is a tension in the Linux world about people who want an open source UNIX and people who want an open source Windows. Systemd is much more a "Windows" approach to system configuration management than a "UNIX" approach.
That isn't "bad" per se but it makes for some confusing things. I would be ok if Linux became the open source windows flavored OS and Freebsd became the open source unix flavored OS. I believe such an explicit step would help folks move forward with "where" a certain idiom of OS management should land in the open source world. Of course I don't expect that to happen :-).
I keep coming back to that. It seems to me that there is a tension in the Linux world about people who want an open source UNIX and people who want an open source Windows. Systemd is much more a "Windows" approach to system configuration management than a "UNIX" approach.
That isn't "bad" per se but it makes for some confusing things. I would be ok if Linux became the open source windows flavored OS and Freebsd became the open source unix flavored OS. I believe such an explicit step would help folks move forward with "where" a certain idiom of OS management should land in the open source world. Of course I don't expect that to happen :-).
I would be ok if Linux became the open source windows flavored OS and Freebsd became the open source unix flavored OS.
why doesn't anyone else view systemd as the direct assault on GNU that it is?
RPC Backdoors? Care to elaborate on this for me?
Perhaps you could ask yourself "how, as a non-free software developer, could I use systemd's RPC system to bypass the LGPL and GPL's requirements that all related software and derivative software must be licensed under the same license?"
The answer will come quickly, I bet. it's how you figure out magic tricks, as well. :)
The answer will come quickly, I bet. it's how you figure out magic tricks, as well. :)
> Systemd is much more a "Windows" approach to system
> configuration management
There would be a comparison to Mac OSX, which has rounded the corners of init with its own approach.
It's also worth mentioning that all mainstream unix (even OpenBSD) deviates from unix philosophy in places. A trivial example - the way that /bin/ls changes behaviour depending on whether it's outputting to stdout or to pipe. If there's a gold standard, it's Plan 9. And almost nobody uses that.
I'm not fully qualified to have my own opinion on launchd, although people who I respect fully describe it as being a very poor init system.
theres some discussion here though: https://forums.freebsd.org/threads/systemd-vs-launchd.44973/
(I'm just commenting to make sure people know that OSX's init system is not exactly without major criticism from people who know there stuff)
theres some discussion here though: https://forums.freebsd.org/threads/systemd-vs-launchd.44973/
(I'm just commenting to make sure people know that OSX's init system is not exactly without major criticism from people who know there stuff)
systemd is 100% free software, unlink Windows. systemd has a command line interface unlike most Windows tools. And I don't know what is the Windows init system but I doubt it is similar to systemd. It's probably much closer to the Mac OS X init than Windows'.
Seriously, it does not make any sense to say that systemd is a "Windows" approach.
Seriously, it does not make any sense to say that systemd is a "Windows" approach.
Not only is it Free Software, but LP was nice enough to make the entire thing accessible over RPC, so that non-free software could easily integrate with the OS at the lowest levels (PID1!), bypassing GPL/LGPL restrictions, and removing much of the reason to write Free Software on Linux at all.
How this isn't worse than Tivo-ization (the reason the GPLv3 was written!), now how RMS/Moglen aren't screaming about this, I'll never know.
How this isn't worse than Tivo-ization (the reason the GPLv3 was written!), now how RMS/Moglen aren't screaming about this, I'll never know.
Well, traditional UNIX is also accessible over RPC usable by non-free software. They're just known as pipes.
Spawning processes and communicating over pipes is a UNIX tradition and also lets you sidestep the GPL. Should RMS be screaming about that too?
Spawning processes and communicating over pipes is a UNIX tradition and also lets you sidestep the GPL. Should RMS be screaming about that too?
Did you really just compare systemd (giving non-free software a PID1 GPL backdoor) to Unix pipes?
Maybe you can explain what a "derivative work" means to you, in relation to the GPL?
Maybe you can explain what a "derivative work" means to you, in relation to the GPL?
I like the rationale that services should be represented by a graph, and I'd like to see this pick up on BSD (it's not terribly complicated to implement on top of init).
However, systemd goes way beyond that, and tries to control everything too much, in too granular detail. I wish the move from init -> systemd had been more gradual, there was no need to rewrite absolutely everything around init.
However, systemd goes way beyond that, and tries to control everything too much, in too granular detail. I wish the move from init -> systemd had been more gradual, there was no need to rewrite absolutely everything around init.
init was the foot in the door that LP needed to start his larger rewrite of Linux into a non-GNU creature.
I don't follow.
Application containers were born out of a variety of reasons, but primarily seem to be oriented around partitioning a host OS into individual resource namespaces each with its own library context. Thus, an attempt to address the fact that the host OS is deficient in providing a multi-tenant experience out of the box.
In fact, application container deployments frequently don't use an init and process supervisor at all, but when they do it's a bare minimum loop that reaps zombies and reexecs a process on SIGCHLD.
On the linux side, the kernel will start to play second fiddle to the systemd.
That much is true, for better or for worse. systemd and much of the new desktop userland is refactoring a lot of kernel components into userspace, creating the de facto equivalent of an unwieldy hybrid kernel. I suppose Tanenbaum did win that debate, after all. Sort of.
in the debian world, the package management system has become more significant than the kernel.
The package management infrastructure is basically what makes a Linux distribution a "distribution". It's the backbone. That you can create Debian stacks based on non-Linux kernels is because many Linux packages are cross-Unix.
as a development platform you'll be able to quickly put together application stacks using microserves in a way that hasn't been practical until now
Wikipedia defines microservices as:
It seems like a daemontools-style toolkit approach (e.g. s6, nosh, perp, runit, etc.) fits the "microservices" umbrella far better. Indeed, I've been seeing plenty of container configurations based on those tools.
Application containers were born out of a variety of reasons, but primarily seem to be oriented around partitioning a host OS into individual resource namespaces each with its own library context. Thus, an attempt to address the fact that the host OS is deficient in providing a multi-tenant experience out of the box.
In fact, application container deployments frequently don't use an init and process supervisor at all, but when they do it's a bare minimum loop that reaps zombies and reexecs a process on SIGCHLD.
On the linux side, the kernel will start to play second fiddle to the systemd.
That much is true, for better or for worse. systemd and much of the new desktop userland is refactoring a lot of kernel components into userspace, creating the de facto equivalent of an unwieldy hybrid kernel. I suppose Tanenbaum did win that debate, after all. Sort of.
in the debian world, the package management system has become more significant than the kernel.
The package management infrastructure is basically what makes a Linux distribution a "distribution". It's the backbone. That you can create Debian stacks based on non-Linux kernels is because many Linux packages are cross-Unix.
as a development platform you'll be able to quickly put together application stacks using microserves in a way that hasn't been practical until now
Wikipedia defines microservices as:
In computing, microservices is a software architecture
style, in which complex applications are composed of
small, independent processes communicating with each
other using language-agnostic APIs. These services are
small, highly decoupled and focus on doing a small task.
It seems like a daemontools-style toolkit approach (e.g. s6, nosh, perp, runit, etc.) fits the "microservices" umbrella far better. Indeed, I've been seeing plenty of container configurations based on those tools.
"Application containers were born out of a variety of reasons, but primarily seem to be oriented around partitioning a host OS into individual resource namespaces each with its own library context. Thus, an attempt to address the fact that the host OS is deficient in providing a multi-tenant experience out of the box."
Given that multi-user and multi-tasking is pretty much a massive hack on what is at the core a single task, single user design, no surprises there.
I say a massive hack, as a CPU is in essence an assembly line. It takes data and processing directives in one end and spit processed data out the other. What multitasking does is basically to halt the assembly line mid job, documents its state, clear it out, and then load onto it the state of a different job. And so it goes, cycling through all the tasks.
Then again, the apparent reason for the discontinuation of Consolekit in favor of Logind was that the latter, via its ties to systemd-as-init-and-cgroup-manager-in-chief, was multi-seat.
A concept where one pretty much recreates the mainframe on the desktop by logically assigning disparate IO devices to a "seat", and so in essence creates terminals. Apparently this is supposed to work while still maintaining the ability to plug and unplug IO devices at will. Quite the rabbit hole.
Given that multi-user and multi-tasking is pretty much a massive hack on what is at the core a single task, single user design, no surprises there.
I say a massive hack, as a CPU is in essence an assembly line. It takes data and processing directives in one end and spit processed data out the other. What multitasking does is basically to halt the assembly line mid job, documents its state, clear it out, and then load onto it the state of a different job. And so it goes, cycling through all the tasks.
Then again, the apparent reason for the discontinuation of Consolekit in favor of Logind was that the latter, via its ties to systemd-as-init-and-cgroup-manager-in-chief, was multi-seat.
A concept where one pretty much recreates the mainframe on the desktop by logically assigning disparate IO devices to a "seat", and so in essence creates terminals. Apparently this is supposed to work while still maintaining the ability to plug and unplug IO devices at will. Quite the rabbit hole.
with all of the above in mind, how does anyone think that SystemD is anything but an attack on GNU/Linux?
I wish there was something [lighter|simpler|more portable|more unix] than systemd.
Your best bets are probably s6 or nosh. If you want just a service framework without init, then you can look at OpenRC, too.
http://skarnet.org/software/s6/
http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...
Your best bets are probably s6 or nosh. If you want just a service framework without init, then you can look at OpenRC, too.
http://skarnet.org/software/s6/
http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...
Thanks for the links - I'm sticking with Debian for now so I guess I'm using systemd for the foreseeable future there, which I [do|dont] have a problem with. systemd hasn't failed me yet - it really does just make me feel 'weird'.
feeling uneasy about a software decision you didn't make is one of the reason many of us switched from Windows to Linux in the first place. It's a little weird seeing people make the same rationalizations I made with Windows.
For the servers I run, boot time isn't an issue. I might reboot a server once a year, and booting in 10 seconds vs 40 seconds isn't really an issue. What is an issue for me is stability. I don't really care about "hideous shell scripts" as long as they work.
Virtual machines, containers and appliances all require very short boot times, because they may be created and booted frequently.
Sometimes it feels as if these would be better served with the age old DOS flat files than something as convoluted as a *nix init.
This because if a "service"/daemon fails to come up, you may as well scuttle the whole VM/container/appliance and spin up another in its place.
This because if a "service"/daemon fails to come up, you may as well scuttle the whole VM/container/appliance and spin up another in its place.
But linux isn't all about servers, there's a lot of desktop users out there.
And having desktop and server diverge at a kernel/init level seems too much burden to maintain.
And having desktop and server diverge at a kernel/init level seems too much burden to maintain.
no, there are almost no desktop users out there; certainly, far fewer, probably by two orders of magnitude, than server and embedded installations; and the divergence in favor of doing things the desktop developers' way is very much the tail wagging the dog.
There's always http://smarden.org/runit/
You can sub syslog with any component systemd has cannibalized and write the exact same article.
That's what the whole argument was all about.
That's what the whole argument was all about.
The people who say "it's not that bad" are those who haven't interacted with these extremely reliable and integral parts of a Unix system for years and years and understand the ramifications of bad behavior.
The author of this article has done so, and seems to think that until this syslog interaction it hasn't been too bad:
> One of systemd's strengths until now has been that it played relatively well (sometimes extremely well) with existing systems, warts and all.
> One of systemd's strengths until now has been that it played relatively well (sometimes extremely well) with existing systems, warts and all.
So systemd has a few bugs that affects its interaction with syslog. I see nothing to indicate this is specifically because of some ill will towards it.
Is there a bug report with a dismissive reply? Or one being ignored?
(I do agree that it shows that systemd is too immature for critical production environments)
Is there a bug report with a dismissive reply? Or one being ignored?
(I do agree that it shows that systemd is too immature for critical production environments)
> Is there a bug report with a dismissive reply? Or one being ignored?
That's always my reaction to blog posts like this as well. A blog post is not a bug report. Given the mentioned bug in the systemd/syslog interaction that made it into RHEL, there should be a bug in the RHEL bug-tracker, and I'd hope it'd be a high priority one.
That's always my reaction to blog posts like this as well. A blog post is not a bug report. Given the mentioned bug in the systemd/syslog interaction that made it into RHEL, there should be a bug in the RHEL bug-tracker, and I'd hope it'd be a high priority one.
I think the issue is just stability in general. I just moved to a new server recently, and I decided to go with CentOS 6 instead of 7, as people were reporting that CentOS 7 is just a little less stable in general than 6. (Although systemd probably isn't entirely responsible for the lower stability in CentOS 7, it probably is one of the major changes in CentOS 7 so it likely takes a good share of the blame).
You always end up with bugs in released software, even CentOS. Some bugs only show up in certain situations, and might be difficult to track down. The only way to give a good guarantee of stability is for a large number of people to use the damn thing for years on end!
You always end up with bugs in released software, even CentOS. Some bugs only show up in certain situations, and might be difficult to track down. The only way to give a good guarantee of stability is for a large number of people to use the damn thing for years on end!
If systemd had no ill will towards syslog, there would be no journald.
No, journald has its own benefits. Creating an alternative to some software doesn't mean you have ill will towards it.
A compatible alternative to syslog would have been healthy. An incompatible that is the only thing properly supported by systemd is not.
I don't know why you're being downvoted. can someone enlighten me?
you're not allowed to dislike system-d nowadays.
seems like every time I make a valid point against systemd it's flagkilled instead of being replied to.
seems like every time I make a valid point against systemd it's flagkilled instead of being replied to.
I've taken to lurking on #systemd in order to see when they sound the bells for an HN thread takeover.
So this means any logging/auditing software that requires the data to be sourced from syslog is unreliable. This kind of behavior would make an auditor's head spin.
If you are auditing systems based on systemd (or sysvinit or makefiles or upstart or launchd) then you are probably doing it wrong anyway
If you build a custom logger into a startup/scheduler instead of using the existing logging component, you're doing it wrong.
Really, if you're not using the logging mechanism to check a system, what are you using?
Really, if you're not using the logging mechanism to check a system, what are you using?
I only watched part of the systemd wars from the side line and to this day I haven't come up with a reasonable solution. Both sides have reasonable arguments.
Saying that a tool is unsupportive towards another tool because in the interaction two irregular bugs happen sounds like a weak claim though. Don't all tools have bugs? What makes these two special?
Saying that a tool is unsupportive towards another tool because in the interaction two irregular bugs happen sounds like a weak claim though. Don't all tools have bugs? What makes these two special?
And the PR division is already in action in the comments...
The PR division is the entire userbase of Fedora, Arch and a few other distributions who have been using it for years without any issues.
I use arch and still despise it. The reduced boot time isn't worth the headache the overly complex systemd suit of tools has introduced. BSD might have some issues, but it worked very well for my use-cases.
To me systemd is not the reduced boot time but the simplified service management.
To me, as an Arch user, sytemd has been responsible for a series of btrfs kernel panics. I'll probably switch to Gentoo just to not have to deal with working around journald the next time I have a choice of distribution.
No, it's not. Just because you use Fedora or Arch doesn't imply that you aggressively support every architectural choice that they have made.
While I agree that systemd does not play nicely with syslog, you quickly realize that journald can be exported as JSON, filtered, described as time ranges, chunked and easily imported into ELK. My users (mainly developers) with less sed/awk fu have come to rely on these features heavily. I'm not really sure what there is to miss about syslog or syslog-ng when you have a robust ELK+journald system.
Unfortunately it's also very slow. Text files don't have the many advantages you outline, but in everyday use they are much faster than the C journal API.
The whole blog is interesting to read. Thanks OP.
Quoting from the systemd wiki [1]:
So the fact that keeping your regular syslogd wasn't as simple as merely symlinking syslog.service was publicly known, but often overlooked by proponents during discussions.
[1] https://wiki.freedesktop.org/www/Software/systemd/syslog/