Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[fscan]

systemd is in our tree because 1 developer likes it, but Gentoo has not adopted it as its default. My opinion is that hell will freeze before we do. The general experience that we have had with the systemd developers is exactly what Linus said. A group of us started eudev when we decided that we could no longer tolerate it.

By the way, you are thinking of sysvrc, not sysvinit. sysvinit is nothing more than /sbin/init and /etc/inittab. /etc/init.d is part of sysvrc. Quite frankly, I agree that sysvrc is awful. Gentoo uses OpenRC to replace sysvrc and it works very well for us. Many things systemd claimed to achieve over sysvinit were already done in OpenRC.

One of the reasons i ditched Gentoo. After having a stable and nice system with systemd when the udev merge came, the fighting between the systemd and udev maintainer started and the build broke every few days. Reading the mailing lists was like watching children fight over their toys.

I'm very happy with Arch now.

[fscan]

What's the journald equivalent of 'grep -R something /var/log/*'? Grepping isn't just OK, my friend, grepping is bread and butter for someone who needs to fix obscure issues and needs to fix them fast.

for the off chance you are not trolling:

i don't know why you think grep would suddenly stop working.

Next to the possibility of filtering specific fields (which you cannot do reliably in a normal log file), you can always just grep the output (journalctl | grep something).

[ryao]

One of the reasons i ditched Gentoo. After having a stable and nice system with systemd when the udev merge came, the fighting between the systemd and udev maintainer started and the build broke every few days. Reading the mailing lists was like watching children fight over their toys.

I'm very happy with Arch now.

If systemd is the reason you use your computer, I think you will be very happy with Arch.

[Gusar]

No they wouldn't.

You see value in a feature, and yet you call it bloat. That makes no sense.

See, systemd is modular in theory but in practice it's not because in practice it isn't a thing in itself. When you install a Linux distro most of the time you deal with sets of binary packages. Disabling components at the level where init operates means you'll have your own distro to maintain. So you either accept the wholesale deal or switch to another distro that doesn't use systemd. Having alternatives is little comfort when you can't really use them because their role is hijacked by the init system.

networkd doesn't hijack anything, it can easily be disabled. journald has the ability to forward everything to your classic logger, so it doesn't hijack anything either. logind is a very special beast, but it's not systemd's fault that no one stepped up to maintain consolekit, even after several calls for it. binfmt is a bit special, I've read Debian's implementation provides more than systemd's, but that's a distro specific thing, so the distro can disable systemd's implementation at compile time and ship their own in their binary packages. Other services, like timedated, are so small I don't see why you'd want to use someone else's implementation on a systemd system just for the sake of it.

Maybe there's some merit in your point, but it's not nearly as big of a deal as you're making it.

What's the journald equivalent of 'grep -R something /var/log/*'?

If you haven't been forwarding logs to a classic logger, "journalctl -o short | grep -R something". There might be something more elaborate, but with this one you're even using the exact same tool as before.

Grepping isn't just OK, my friend, grepping is bread and butter for someone who needs to fix obscure issues and needs to fix them fast.

My point wasn't that grepping isn't valuable, it's that journald provides further functionality than just that.

[Scias]

What's the journald equivalent of 'grep -R something /var/log/*'? Grepping isn't just OK, my friend, grepping is bread and butter for someone who needs to fix obscure issues and needs to fix them fast.

Not only you can still use grep and all the other beloved tools you want with journalctl's output, but journalctl gives the ability to quickly filter specific fields without needing to spend a night on grep and regex patterns.

A few examples :
journalctl -u NameOfService # Shows only log from a specific service
journalctl --since=date1 --until=date2 # Shows log from date1 to date2
journalctl -b ID # Shows log from a specific boot
etc...

Honestly I find this much more effective, reliable, simple and fast than simply grepping text files to filter out the noise and find the right issues. Now you're not obliged to use journalctl at all when using systemd so I don't see why there's a complain about it.

[schmidtbag]

y'know what I'd really like to see? systemd get divided among separate packages. No need to fork the project, just simply split it. There should be a systemd-core, which contains only the necessities of an init system (basically the same thing as sysvinit, with a few other things here and there like parallelization) and then separate packages that include these other bloat features that some people may sincerely care about or want, but aren't vital to the infrastructure of the OS. This should be much easier to maintain and make everyone happy. I don't think anyone would dislike systemd if it were designed like this.

[fscan]

If systemd is the reason you use your computer, I think you will be very happy with Arch.

After i tried systemd i didn't want to go back ... nothing changed in this regard.

But primarily i was loosing trust in the developers. Having a unstable system because of package maintainers fighting does not inspire confidence. I don't want to bash Gentoo and all the hard work their developers are doing, that was just my personal experience.

and yes, i am happy with arch.

[jrch2k8]

If systemd is the reason you use your computer, I think you will be very happy with Arch.

well i use gentoo and arch both with systemd, i don't mean openRC treat me badly but systemd is just too far superior for my needs(TM), Cgroup PID1 is absolutely awesome for security and for tracking properly and accurately child/rogue/zombie/spawned processes(and for developers too) + make sure all your childs are gone when your main PID app is gone.

Another killer feature is the virtualization detection in systemd especially in applications that need that info in an accurately fashion(tested on lxc,kvm,xen and work flawlessly)

standarized DBUS api is a dream come true, service files are really powerful, logind and company are actually really badass, journald is very good and accesible from API, reliable process spawn through DBUS, etc.

but the bigger killer feature is standarization, i can develop my apps and just chop thousands of lines of code to handle all kind of sysV era per distro ugly hacks and just add a nice plugin to my apps(QT5 commercial) that talks to systemd in few houndreds of lines top and the best part is that it will work as intended in Fedora, Arch, Gentoo(if you emerge systemd), Opensuse, Ubuntu(in the future), Debian, etc without any extra effort.

so for the regular non techie user probably openRC is as functional as systemd but for developers and security aware powers users systemd wins everytime because it make your life so much easier and offer real solutions to real problems that developers face everyday in non systemd systems and that is a good thing.

my advice to you ryao and gentoo devs, since i notice that maybe you havent taken all scenarios in consideration before state you love for OpenRC is that maybe you guys should focus on provide similar advanced functionality(without changing the API when possible pretty please) or maybe even try to find a common ground to work with systemd devs(i know they can be a hard bunch to deal with sometimes), so you can contribute the best of OpenRC to systemd and improve the code(eudev is a nice example that thing can be further improved and gentoo devs value)

[V10lator]

After i tried systemd i didn't want to go back ... nothing changed in this regard.

Same here, but I'm still using Gentoo.

[prodigy_]

journalctl -o short | grep -R something

O'rly?

/sigh

The saddest part is that I got more or less the same reply from three people and it's painfully obvious that none of you even tested your "solution". That's why we can't have nice things (anymore) I guess.