Busybox Deletes Systemd Support 572
ewhac writes: On 22 October, in a very terse commit message, Busybox removed its support for the controversial 'systemd' system management framework. The commit was made by Denys Vlasenko, and passed unremarked on the Busybox mailing lists. Judging from the diffs, system log integration is the most obvious consequence of the change.
Deleted more than systemd support (Score:3)
The Commit Message (Score:5, Informative)
remove systemd support
systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them.
Re:The Commit Message (Score:4, Insightful)
I'm not aware of the politics in this, are they saying the systemd people are rude, or that they just refuse to make their code compatible?
Also with regard to systemd, I really do like distros that have it in my virtual machines because I can do a full reboot in seconds, whereas other distros take much longer. This is just flat out awesome for reducing lost time during maintenance when something doesn't go as planned.
Is there a particular reason we can't have something like that AND comply with the "do one thing and do it well" rule? I'm not familiar enough with the low level stuff.
Re:The Commit Message (Score:5, Informative)
I'm not aware of the politics in this, are they saying the systemd people are rude, or that they just refuse to make their code compatible?
Both.
People have found bugs that make systemd incompatible with existing programs, and rather than fix the bugs in systemd, the systemd people responded that the people who found the bugs should work around systemd and systemd didn't need to be compatible with existing code.
Basically systemd completely wrecks the UNIX way and makes the distros that use it absolutely unmaintainable if you're a sysadmin.
Re: (Score:2, Interesting)
So far, systemd has made my life easier. The company I work for has written custom daemons. I'm expected to get the software deployed into AWS. It is very easy to whip up a systemd script to manage the software no matter what quirks the software has about running as a daemon. I have also noticed that systemd does a much better job making sure daemons get shutdown. Java programs seemed to be the worst when it came to shutting them down. Systemd gets the j
Re: The Commit Message (Score:5, Informative)
There was a problem involving systemd, networking, and aiccu.
The aiccu maintainer demonstrated how systemd wasn't properly making sure that networking was up before attempting to start aiccu, something pretty much any other init system managed to do.
The systemd folk, by way of Red Hat basically told those using aiccu the same thing others were told: 'too bad, systemd isn't betting "fixed" because we don't see this as our problem.'
My opinion? Systemd is useless and makes more problems than it's worth. It has its mitts in far more than any init system should. It is a blight on system administration.
Re: The Commit Message (Score:5, Insightful)
There was a problem involving systemd, networking, and aiccu.
The aiccu maintainer demonstrated how systemd wasn't properly making sure that networking was up before attempting to start aiccu
No they didn't demonstrate that. The relevant thread is this one [redhat.com], and the short version is that the aiccu author failed to understand that the network being unavailable temporarily is quite a different failure mode than, say, the configuration file having a syntax error. In the latter case, it's OK to terminate and require user intervention, whereas in the former case, if you're a long-running daemon that's supposed to keep a tunnel open, you keep running, backing off exponentially and waiting until the network becomes available again. Or at the very least, you exit with a specific exit code so that somebody can write a wrapper script that handles this particular error correctly and implements the backing-off thing in the wrapper script, and still terminates permanently for any other error condition (at which point it's fair to ask again why you wouldn't implement the exponential backoff in the daemon itself).
This whole thing is quite independent of the init system; sysvinit will expose just the same set of issues. What's broken is the daemon, not the init system.
Re: (Score:3)
aiccu then crashes and it never starts again.
I may be miss-understanding something, but if a service crashes, SystemD is responsible to restart the service. In this case the service may just crash again, but that's besides the point. Why wasn't SystemD bringing a crashed service back online?
It did, after the submitter wrote Restart=always/RestartSec=10 into the service definition file. But that led to the (understandable) concern on the part of the aiccu author that when this patch was rolled out to all Fedora installations, you might have thousands of Fedora boxes out there with e.g. a wrong tunnel password in the aiccu configuration, and all those machines would then be continuously hammering the SixXs tunnel broker with rejected connection attempts. Stuff like that is one of the reasons why
Re:Let him have Czechoslovakia if it keeps him qui (Score:5, Funny)
Re:The Commit Message (Score:4, Insightful)
I understand that your life is easier, but this topic is about Busybox. Their life was made harder, just like many other people who are not satisfied with systemd. Obviously, you are a sysadmin with some own development, not a distro maker who tried to integrate 10+ applications where one of them doesn't want to cooperate with the rest.
Re:The Commit Message (Score:5, Insightful)
Indeed. And that is another reason to not have any dependencies on systemd, as you are then bound to one platform and are at the mercy of one company. Not smart.
Re:The Commit Message (Score:4, Insightful)
I think it is telling that poettering (note he has his hands in the design/state of systemd/dbus/pulse audio/XDG/PAM/...) when seeing a complaint that su - does not pass/or instantiate XDG under systemd came to the conclusion that su is broken and reimplemented it in systemd. The reality is that his designs for these systems disregard unix/posix and the issue in the bug report was directly related to how he designed XDG/dbus/systemd and pam -- not an issue with su.
He has also gone on record stating that he does not care about linux and unix compatibility, that he is building things that he wants to. Given that systemd is now up to 100+ bins and is wrapping everything from init to logging to virtual machine management to auth privilege tightly coupled to dbus it really sticks like most of the crappy design decisions that made windows lose in the server market. One of the core reasons unix is so powerful is that even on a full upgrade of a system you can pull out software and migrate easily and that is because there is loose coupling on all of these parts.
Re:The Commit Message (Score:5, Insightful)
systemd does things like auto-detect all of the tty devices, and automatically associate them with login prompts when the device becomes active. This sounds good, until you hit an application where the tty device should not have a login prompt. After two days of trying to work around the issue (there is a work around), I now understand what everyone was complaining about ...
The biggest issue is that everything is wrapped in layers of configuration scripts, and this makes it is difficult to do something specific. The distros in an effort to "make everything easier" then have their own distro-specific scripts, and this makes the problems even worse.
The old way had one configuration script per activity, and this had the advantage that you only had to worry about one script.
Re:The Commit Message (Score:5, Informative)
> Both.
It's not all the systtemd people. But the problem starts right with the technical leadership, Leonart Pottering. systemd is attempting to do _too many_ things. Daemon management, _and_ logging, _and_ network management, _and_ automounting, _and_ privilege management, _and_ Leonart has stated that the gola is a "stateless Linux" where no system specific configurations are stored in "/etc": they're all migrated to systemd configuration tools.
The result is not only much too large, it's not cross-platform, because systemd _cannot_ run anywhere but Linux due to the kernel changes required. It thus creates a Linux lock-in, breaking broad availability and usability of services oriiginally compiled for Linux.
Re:The Commit Message [Citation begged for] (Score:5, Insightful)
LaunchD has existed for a long time and is fully opensource and well tested. It has gotten the run-through with iOS which needs to be easy to use and work reliably in some very complicated environments, like cell phones. Of course there is the very strong "not invented here" mindset that a lot of GPL people have. Comparing SystemD to LaunchD is like comparing btrfs to ZFS. The most annoying mind-set that I've seen from the SystemD people is the whole "if everything is working as expected, this situation should never happen, so we may as well not handle this situation". How I hate that. If you know about a failure case, handle it! I hate that "limp along and some time later, fail in some unrelated way that gives the wrong impression". Works great when it works, but the failure cases are a mess.
Did you know that both LaunchD and ZFS had numerous old-school Unix people working on them in all stages of development? These are people who grew up using and managing mainframes and many now make a living managing datacenters. Who would you rather having designing the critical infrastructure of your OS. A sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are, or some wide-eyed dev who likes flashy things and assumes the wisdom of a sysadmin is just the rantings of some old person?
Mind you, I'm a fairly young person that loves flashy things, plays AAA video games, and watches anime, not some neck-beard.
Re: (Score:3)
As far as failure cases the people pushing systemd the most strongly are the people who run the most sophisticated date centers and cloud OS installations that run the internet.
I don't think that's true lol.....you are the only person in that category I've ever seen who favored systemd. And from what I gathered discussing it with you previously, you only like it because of features you hope will eventually make it into systemd (features which I think will never make it, but that's predicting the future so who knows).
Re: (Score:3, Insightful)
> the people pushing systemd the most strongly are the people who run the most sophisticated date centers
This kind of dismissive attitude is a classic example of the systemd problem. It's fanboys just baselessly assume that anyone who's not on board is "just an amateur". Both parts of that are quite wrongful. That includes the assumption about the experience of critics AND the idea that the "amateurs" don't matter.
If Redhat wants to build "pretentious cloud Linux" they should just do that and leave the r
Re: (Score:2)
Wouldn't the best approach be to use the kernel firewalling capabilities to block everything that isn't needed for the function of the daemons running on the box, including configuring the box for out-of-band management, so that the only thing that can be touched from the user-side is the particular set of daemons necessary for its function? That would allow you to update that particular application without having to restart the computer every time, and would ensure
Re: (Score:2)
That's not what it's for. See my above post.
Re:The Commit Message (Score:5, Informative)
Systemd has taken an all or nothing approach for its components, and it has enveloped several significant components such as udev/upower/udisks. What this means in practice is you either have to take all of systemd (i.e. replace your init system, syslog, etc.) to use any of the components it has absorbed or you need to fork and maintain what you need yourself.
Here's a personal example: I use Gentoo an MATE as a desktop which in turn uses upower for suspend & hibernate. The latest version of MATE requires the latest upower (now dependent on systemd) to support those functions. So now if I upgrade MATE, I have to either replace my init system (OpenRC) with systemd or not have those upower features on my laptop.
Forcing their users(or distros) hand like that is not playing well with other software and I applaud Busybox for standing up.
Re:The Commit Message (Score:4, Insightful)
The latest version of MATE requires the latest upower (now dependent on systemd)
That's what you get when you use open source software. If the developer decides they want to become dependent on systemd then it's their project and they can do what they like, and you have no control over it. If you don't like it your only option is to fork.
That's not a criticism, it's just a statement of the way it is. No point getting upset about systemd and other software that now relies on it, because it's not like the developer owes you anything. That's the price of freedom - other people are free to do things you don't like.
Re:The Commit Message (Score:4, Informative)
That's what you get when you use open source software. If the developer decides they want to become dependent on systemd then it's their project and they can do what they like, and you have no control over it. If you don't like it your only option is to fork.
As opposed to what you get when you use closed source software. If the developer decides they want to become dependent on systemd (or whatever) then it's their project and they can do what they like, and you have no control over it. If you don't like it your only option is to go fuck yourself, because you don't get the source. You're going to have to move to a competing project, if you can even manage that because that closed-source program is actually standards-based (often it is not) and you're not locked in.
That's not a criticism, it's just a statement of the way it is. No point getting upset about systemd and other software that now relies on it, because it's not like the developer owes you anything.
The developer of a closed piece of software doesn't owe you anything, either. You paid for a piece of software, and aside from being fit for the stated purpose, they don't have to do anything for you. If they make architectural changes with which you disagree, you simply have no recourse, unlike OSS, where at least a fork is possible.
OSS is clearly superior to closed software in this regard. There's not even a counterargument to be made.
Re:The Commit Message (Score:5, Informative)
The logical follow up question is why does upower depend on systemd?
The team decided they didn't want to duplicate support for suspend/hibernate when there's already a tool which does so. At the same time they released a solution for those people without systemd:
UPower discontinued hibernate and suspend support in favor of systemd.
Because of this, we have created a compability package at
sys-power/upower-pm-utils which will give you the old UPower with
sys-power/pm-utils support back.
Some desktops have integrated the sys-power/pm-utils support directly
to their code, like Xfce, and as a result, they work also with the new
UPower as expected.
All non-systemd users are recommended to choose between:
# emerge --oneshot --noreplace 'sys-power/upower-pm-utils'
or
# emerge --oneshot --noreplace '>=sys-power/upower-0.99.0'
However, all systemd users are recommended to stay with sys-power/upower.
So what exactly is the problem? Why exactly is systemd so evil because someone else doesn't want to maintain a certain effort they are doing and instead hand off to another package, while even providing a compatibility option for the anti-systemd crowd?
Re: The Commit Message (Score:4, Informative)
As another poster has identifies, the problem seems to be that the systemd people aren't coding to interfaces. If they were, then dependencies wouldn't be on specific code, i.e. the implementations.
Upgrading software shouldn't require a change to the init system.
Re: (Score:2)
I run Debian Sid ( yes I know that maybe the problem) and since SystemD was installed, my bi-monthly reboots are slow in the order of 2 to 5 minutes.
What is happening is that systemd is not turning the network on correctly, and it waiting forever to mount the NFS shares. When it finally gives up, I just open up a terminal, ifdown eth0, then ifup eth0 and all is well. I guess systemd can't handle a static IP on a desktop.
Re:The Commit Message (Score:5, Funny)
I'm not aware of the politics in this, are they saying the systemd people are rude, or that they just refuse to make their code compatible?
They indent using four spaces, and also apply this indentation to the braces at the start of a function. Spaces! Four of them! Not tabs, spaces! And they indent their braces!
Removal from Busybox is too good for them, they should be exiled from the planet!
Re: (Score:2)
Oh boy your reboot takes 10 seconds less. Ever boot big hardware? That shit can take 10 minutes alone.
Re:The Commit Message (Score:5, Informative)
I keep the systems configured so that in the event of a complete power outage, EVERYTHING must come back up without any intervention required. This is saves a lot of explaining when it's time to put out a fire and -- oh shit, the admin forgot to document how to get everything back up and running when somebody crashed their car into a nearby transformer and the UPS failed to signal the diesel generator to start, and now we're spending 3 days trying to get shit working again because the guy who set it all up quit about 5 months earlier. (Yes, I've seen exactly this happen before.)
The reboots are only necessary when testing changes to make sure that everything comes up the way it's supposed to in the event of a total loss of power. Sometimes this doesn't happen (for example, a new kernel image breaks ZoL, so after the reboot the array doesn't get mounted) and it might take multiple reboots before you've got it all set.
Re: (Score:3)
I can do all of this with a standard Linux/Unix and without systemd.
What kind of low end admins are you hiring that don't make sure things come back up after a hard reboot? My final test actually is yanking the power cord out and plugging it back in.
Honestly this is system admin 101 stuff.
Re: (Score:2)
Why are you rebooting your machine so freqently that the time that systemd might save at boot time should even matter so much?
I'm writing a service that runs on a cloud service provider. When I come to sit down at my desk and deploy it for the first time, it spins up a VM. When I finish coding, I shut down the VM. So when I'm authoring this kind of program, I experience "VM boot-time" once or twice a day.
Re: (Score:2)
When you're writing scale-on-demand cloud applications, the boot time of a new vm is most of the latency of additional capacity coming online.
Re:The Commit Message (Score:5, Insightful)
Your answer is problematic in the same way that the behaviour of the systemd people is problematic: you're essentially saying to the GP: you shouldn't have that problem. I get that a lot in newsgroups: I have a certain problem, I ask a newsgroup, and one of the first responses one gets is: 'you shouldn't want to do that.' No, *I* decide to do that!
Irritating doesn't even begin to describe it. So, the guy wants to reboot often. Maybe he has a very valid use case that you haven't thought of. You can't imagine every possible conceivable use case. But anyway, this is technology - we can make it work - with or without systemd.
Re: (Score:3)
Note I further did not ask why boot time in general should matter.... I asked specifically why they are rebooting frequently enough that the time that systemd is reputed to save at boot time should matter, because it does only amount to a few seconds saved per boot.
Re: (Score:3)
Well, I'm not the OP, but in my case, I run Linux on my laptop, and since I have an SSD, it already boots pretty quickly, IF systemd improves on that, I'm interested.. Since I don't bother to use standby or hibernate, I reboot it a LOT... I'm currently on Ubuntu 14.04, so I only apparently have partial systemd in this version, but I'm under the impression that the next LTS from Ubuntu will have full systemd.. IF systemd improves boot speeds, AND does NOT fuck up everything else, like I hear so many reports
Re: (Score:3)
Why are you rebooting your machine so freqently that the time that systemd might save at boot time should even matter so much?
Because other Slashdot users keep recommending laptops whose suspend is broken in Linux. They recommend that instead of suspending, one ought to log out saving his session, shut down, and start the computer again.
Re: (Score:2)
the person who commit that patch to remove systemd was also the first person to merge a systemd patch [busybox.net] into BusyBox.
Re: (Score:2)
It does not help in discussions if you throw around inaccurate disparaging comments about things you criticize.
What exactly is "good engineering"? I bet finding a consensus on that one won't be easy. So, while you and me feel that systemd isn't well engineered, there will be people (its authors, for one) who honestly believe it is.
If you will talk to people about it, you need to carefully, with well-thought-out arguments, explain *why exactly* it is badly engineered.
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
Seriously though, I don't think systemd is the answer to an init system, but systemd has started to get a lot of competent people thinking about what a good init system should look like. See this for example [darknedgy.net]. I don't think we're at the implementation stage yet, we're still at the brainstorming/exploration stage. It's a difficult problem, and a lot of people have come up with mediocre solut
Re: (Score:2)
The Systemd project has eaten quite a bit of the userspace plumbing (udev and consolekit->logind) for which upstream support is no longer systemd independent. They are also pushing to control future iterations of dbus. To truly be free of systemd, maintainers will have to fork and maintain these modules or otherwise provide equivalent functionality. My guess is that few are willing or able to commit the necessary resources at the present time.
Re: (Score:3)
FreeBSD has not chosen to incorporate Systemd and is doing just fine, thankyaverymuch. They also have more than enough resources to keep it in the shape they'd like it.
Caveat: the FreeBSD team admits something better than init scripts will soon be necessary. But they're taking the time to figure out what and why and how. In the meantime, install FreeBSD or the desktop version that installs easily: PC-BSD, and enjoy a nice systemd-free experience. Oh no, it doesn't boot in 3 seconds! But it also doesn't
Commit Message Missing for Me (Score:5, Informative)
remove systemd support
systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them.
Well, at least someone is willing to say it! (Score:4, Insightful)
With the major distros all moving to systemd, it's nice to see someone burn that bridge. I think if at least one top level distro was anti-systemd, then the drama would all go away, because the group that distrusts systemd could just go there. Someone quick spend your life forking fedora to a non-systemd thing. Pls?
Re: (Score:3)
Re: (Score:2)
Yeah, but Jordan's already implied that FreeBSD will be going down a very similar path....
Re: (Score:2)
Yeah, but Jordan's already implied that FreeBSD will be going down a very similar path....
To be fair, I don't think people are complaining about the idea of systemd--getting rid of clunky old init scripts is a good idea--they're complaining that the implementation of systemd seems to be Pulseaudio 2.0.
I mean, my first experience of systemd was when I tried to install CentOS 7, and systemd crashed during the install. Not really a way to give me warm fuzzies.
Re: (Score:3)
I like init scripts. One can understand them without having to look up the hard-coded keywords for systemd features.
Re:Well, at least someone is willing to say it! (Score:4, Informative)
i bet you didn't like init scripts until you learnt how to code them by looking up and learning from a bash manual.
Some of us learned shell scripting before bash existed. We're perfectly comfortable with shell scripts, thanks. They are a central feature of the Unix operating system, and claiming that they are something to be avoided is only done by people who don't understand Unix.
Re: (Score:2)
Yeah, but Jordan's already implied that FreeBSD will be going down a very similar path....
Actually, from what I've read, they are actually going down the launchd model path, and it's primarily being driven by iXsystems.
I think that most people are not objecting to launchd because Mac OS X uses launchd, and is capable of passing the UNIX conformance tests; it's questionable whether or not a systemd based system could do the same, since in order to pass the tests, it was necessary to make launchd respond to a SIGHUP in the same way that initd did previously.
It was also necessary for it to read fla
Re: (Score:3)
Check out MX Linux [mepiscommunity.org] and antiX Linux [distrowatch.com]. They are not in the top 10 distros but they are solidly in the top 30. They're based on Debian but don't use systemd. They also have some pretty neat features [mepiscommunity.org] and friendly [mepiscommunity.org] communities [freeforums.org].
Awesome news (Score:5, Interesting)
Great work BusyBox!
Now if some of the desktop distros would listen to their core base and drop systemd as the default things would really be looking up for 2015 and next year.
That's not to say some of the ideas in systemd are entirely without merit. But the execution is entirely and utterly wrong. Maybe not for a version of Windows, but totally wrong for UNIX.
systemd deprecation warning (Score:2, Interesting)
If given a choice, the user base stays with what works and quick adopts the better available alternatives. When forced they will look for the quickest out, seeing those that try coercion as a form of damage that must be rooted around.
The best thing to come from this is that the systemd crew have pulled much their code under one umbrella making it much easier to see which bits to replace. Now if they can try a little harder and embrace avahi and pulseaudio in the same way.
Re: (Score:2)
What works - and has worked for decades is the init system.
It's not always the best, but it's easy to manage for a system administrator and it's easy to understand and debug startup problems.
For stuff that takes time in an init script the historical way to solve that was to run that part in the background.
Re: (Score:3)
Oh your sound is probably working, except your sound output is probably not going to the "right" output for you to hear it. Under pulse, headset jack and line-out jack are separate outputs, as are most modern video cards.
That said, pavucontrol ought to be installed by default since it is the easy way to switch outputs, though you can also use pactl (or pacmd I think)
Re: (Score:3)
I'd love to know why a window manager er uh "desktop environment" needs its own sound daemon and associated controls. Sounds like something the OS should handle seamlessly to whatever asks.
Re: (Score:3)
You need controls to pick which output, which the OS can't guess.
What? Yes, it absolutely can make a good guess. If you have HDMI connected to a display with audio conversion/output, send the audio there. Otherwise, send it to an output jack with a cable connected. All the sound cards made for years and years now can detect cable insertion.
systemd problem (Score:2)
I have a problem with my debian server. The problem is that since upgrading to systemd, running fdisk causes the server to mount the partitions from the disk I'm trying to repartition. Even removing them from /etc/fstab doesn't prevent them from being mounted.
I did not have this problem before systemd and God alone know where the stray configuration causing this misbehavior lies.
As I said before... (Score:4, Interesting)
The systemd way (Score:5, Interesting)
Just an anecdote: during a recent upgrade from Debian Wheezy to Jessie, the first boot into the new system failed with a message from systemd about mtab not being a link into /proc/something (a trivial problem as far as I can see).
Can't remember the exact message from systemd, but it was something about being "frozen"
No going into single user, nothing, just F... you and go reboot on the CD image. Happy enough that the machine was on my desk...
And they wonder why many people don't like systemd....
Re: (Score:2)
Re: (Score:2)
I've got end-user boxes with GUIs with uptimes over two months, a couple of servers at five months (last time generator didn't kick-in) and one that's at 731 days. I'm sure that there are others here that can claim significantly longer uptimes than that.
Boot-time is also relatively unimportant on high-availability clusters, as there should be fault-tolerance and redundancy in the cluster so ensure that even if a box is taking its
Re:So who wants to... (Score:4, Insightful)
System boot time is only important if the system is booting frequently.
And pretty much irrelevant when my servers take about five minutes to get out of the BIOS and start running the operating system.
Re: (Score:2)
Let's be honest, faster booting is a nice feature, but not at the cost of lousy architecture and code.
Re: (Score:2)
Wait. Busybox is that thing whereby you take 700 executables and all compile them into one big one, and then have the real main() functions switch argv[0], right? How is that UNIX philosophy? I think both busybox and systemd err against UNIX in that they are big, unmodular, sit too close to the system, and one bug affects a lot of security at the same time.
Re: (Score:3)
All my machines suddenly were taking exactly 90 seconds to boot, guess what systemd was part of an update. Removed systemd boot time is 2 fucking seconds.
systemd folks and redhat are just brain dead.
Re: (Score:2)
Android doesn't use BusyBox. Some SoC providers might in their Android BSPs, but it is NOT standard in Android. The reason is the license - BusyBox is GPL, Android prefers Apache, and the only GPL component in it is the Linux kernel.
Android DOES provide an Apache licensed piece of code that works similarly to BusyBox, but it isn't BusyBox. (Many SoC vendors provide BusyBox in theri BSPs because it aids debugging, while the Android native one provi
Re: (Score:3)
> No one uses syslog any longer on servers so they were correct in dropping syslog messages to discourage its use.
So correct you had to post AC because you'd be frying karma from all the no ones with mod points.
Re: (Score:2, Insightful)
"logging messages just aren't important"?!
I guess you've never worked anywhere that had regulatory compliance requirements. Or ever wanted to debug something.
Re: (Score:2)
> systemd supporters get voted down here irrationally
Can you substantiate that it is irrational? Your posts are literally claiming that professionals suck at their jobs because they don't want to use some flavor of the month component- one specifically designed to alter their workflow, without consulting them.
Re: (Score:3)
Then you haven't had problems trying to figure out WTF systemd is doing on a box. No logs means that it's taking hours to figure out what the problem is - and the problem can be a missing option in a config file that's needed for systemd operation where the error message is thrown away by systemd.
One fine example of catch-22 by systemd.
Re: Dropping stderr and syslog messages... (Score:5, Insightful)
> If you're depending on stderr for troubleshooting, you're doing it wrong.
And so many people are doing it wrong that you need to post AC or have your account go negative karma from all of us wrongbies.
Or maybe a nonmodular approach to something that was well documented and understood, that got glommed into every distro of note, has backlash. Maybe that.
Re: Dropping stderr and syslog messages... (Score:5, Insightful)
If you're depending on stderr for troubleshooting, you're doing it wrong.
What's your better idea?
What do you thing stderr is for?
Re: (Score:3)
It's the trigger for your watchdog service. If it sees anything on stderr, it restarts the application.
Except warning messages are also emitted on stderr, not just abend-worthy messages. If you did this by default to every daemon, your system would completely shit itself.
Re: (Score:2)
Re: (Score:3, Informative)
No. Being able to use less, grep, egrep, awk, cut, etc. is very important.
Re: (Score:2)
If I had modpoints I would have modded up this. Those tools are one of the core tools that every decent admin and *nix user shall know. They are way more powerful than most GUI softwares that have been written ever. Only 'vim' may be a contender there.
Re: (Score:2)
You can still do that, but now you need the new set of those utils to ready binary logs. Tell me again the point of binary logs?
Re: (Score:2)
No, you are the one that's out of touch with some of the more powerful tools for managing text information.
Instead of complaining as an AC and downmodding then I say that you instead should provide us with good information about how to handle the problem of non-existing text logs and missing stderr outputs. The non-existence of them means that problem solving has become a lot harder.
Re: Dropping stderr and syslog messages... (Score:4, Informative)
configure system to forward all logs to syslog or rsyslog for the status quo
Journalctl is well worth getting to know http://www.freedesktop.org/sof... [freedesktop.org]
Re: (Score:3)
Having a file residing in plain text vs having plain text piped to another program is a pretty significant difference. You can't seek around piped input, unless you cache it memory -- which could be resource-consuming. (And maybe your tool for reading piped input is broken because of shared library problems). Being able to read a resting file in plain text is very important in recovery situations.
Re: (Score:2)
But you can't do a 'tail -f' on it to see progress.
Re: (Score:3)
here's a helpful site that gives lots of examples on the power of journalctl. https://www.loggly.com/ultimat... [loggly.com]
Re: (Score:3)
No advantage as far as I can see compared to syslog and the ordinary text tools. Just a way to force the use of binary file processing tools and as soon as something pukes in the binary file it may be completely unreadable. A text file might not look good after a puke but it's still mostly readable.
Re: (Score:3)
Re: Dropping stderr and syslog messages... (Score:4, Informative)
The decision to drop stderr has made my life hell. I wish systemd guys understood how important it is to those of us that run servers.
Maybe I'm missing the point here, but there has not been any "decision to drop stderr". It's clearly possible to set where it should go:
StandardError=
Controls where file descriptor 2 (STDERR) of the executed processes is connected to. The available options are identical to those of StandardOutput=, with one exception: if set to inherit the file descriptor used for standard output is duplicated for standard error. This setting defaults to the value set with DefaultStandardError= in systemd-system.conf(5), which defaults to inherit.
Re: (Score:2)
Wonder why so many other devs are so eager to put the systemd dick in their mouths.
I discussed that topic a bit in my journal [slashdot.org].
Basically, systemd guys did a good job finding out what the init script writers wanted, at both RedHat and Debian, and giving it to them. When the init script writers needed something, they responded. Since the init script writers were the ones who decided if systemd got included in the distro, that was a good idea.
Re: (Score:2)
Those who like systemd almost always talk about features.
Those who dislike systemd almost always talk about architecture and design and code. The Unix way.
Systemd does make things easier for some people and some tasks, which is why it's been adopted. The problem is that it's ugly as sin from an architectural standpoint.
Re: (Score:3)
Systemd does make things easier for some people and some tasks, which is why it's been adopted.
Systemd is funded by Redhat, isn't it? How does it make server administration easier?
I've had to work with a Redhat 7 server at work, and all systemd does is force me to learn new ways to do the things I've been doing for years.
Re:The message in question: (Score:5, Insightful)
Systemd is funded by Redhat, isn't it?
Mostly, yes.
How does it make server administration easier?
I've never heard a server administrator say systemd makes things easier for them. There are probably some server administrators somewhere who will claim that.
Systemd makes things easier for people who write init scripts. Init script writers are the people who have primarily been responsible for its adoption in various distros.
Re: (Score:3)
Linux is controlled by money because its authors have been hired by commercial companies who control their employees. Red Hat management forbids to create competitive solutions, I speculate because Red Hat is partially owned by proprietary IT companties in a risk of FOSS competition.
systemd was created for containers. Containers are a quick&dirty way of packaging. Containers again come from the evil business side of Linux, no sane person would make that debugging nightmare happen.
RedHat was backing Upstart, a Canonical project. Systemd was started by RedHat developers working without the direction of management, it was forces external to RedHat who actually got RedHat on board with Systemd.
I did an Internship with RedHat years ago, I don't know how they compare to other open source companies but in my experience they give their developers a remarkable amount of autonomy.
Re: (Score:3)
Or I could just open a file in gedit.
You are demonstrating the biggest advantage and the biggest downsides to Linux at the same time. The rich and widely available different ways to administer the system, and the self important douchbags in the community who believe their way is the one true way (tm).
You're wrong on this one. If you need a graphical tool to administer your system, you clearly are not meant for sysadmin work.
Most of the time, graphical tools like gedit aren't even usable (like on a constantly changing file) or available.
Re: The message in question: (Score:2, Insightful)
Systemd makes server administration a lot harder - almost a nightmare. There's no way to see how stuff is related anymore, while with init you could see it with a quick glance using ls.
And if you add your own stuff it's not easier, it's darn hard.
Re: (Score:3, Insightful)
ffs, init was 20k LOC systemd is now 100+ bins and 430k LOC. Before systemd you had a log file that was text and parsable using the commands that are core to unix (or specialized applications/services to injest them later), after systemd you have a binary log that mind you has code controlling it that can choose to destroy that log if it finds it is unreadable or corrupted. Init was special purpose and streamlined to do one task well, systemd is coupled to auth, dbus, vm startup and shutdown, vm manage
Re: (Score:3)
It's only by looking at them one at a time and drawing the relations in some external tool that I can figure out how they are related.
It's like going back to stone and chisel to do filing.
Re: (Score:3)
Re: (Score:2)
I can't say that I was thrilled with systemd when it came along, but I realized that it wasn't going away any time soon
That's not much of an endorsement.
People who choose Linux do it because they appreciate a quality OS, well built and put together with care. That's why we like Linux.
If you don't care about quality, you might as well use Windows.
Re: (Score:2)
That's because it wasn't intended to be one. My personal opinion is that for the most part, it's a solution looking for a problem, but I'd rather learn to work with it than waste my time complaining, especially as I don't have the coding skills to do anything about it.
Re: (Score:2)
Learning how to use it isn't that hard, and I don't think you can make valid arguments against systemd until you learn to use it.
Re: (Score:2)
I wonder if thsi topic would have been as controversial or toxic if the systemd people had tried to agree a new set of interfaces first with the community.