Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why systemd is a problem for embedded Linux

kevinboone.me

Post reply on HN
Print view View original

231–240 of 308 posts

Re: Why systemd is a problem for embedded Linux

#231

Post by 1oooqooq »

kaba0 wrote: post #186
1oooqooq wrote: post #184

Earlier quoted context omitted.

it was only faster if you started with bloated redhat systems to begin with. but yes, it was the beginning of parallelism on init... but the "faster boot" you're remembering are actually a joke at the time. since the team working on it were probably booting vms all the time, the system was incredible aggressive on shutdown and that was the source of it. something like it reboots so fast because it just throws everyth…

It mandates strict session termination, unlike the unsustainable wild west approach of older Unix systems. Proper resource deallocation is crucial for modern service management. When a user exits without approval of "lingering user processes," all their processes should be signaled to quit and subsequently killed.

i think the "unsustainable wild west" of sending sigterm, waiting and sending sighup was very good because it was adaptable (you were on your own if you had non standard stuff, but at least you could expect a contract)

Nowadays if you start anything more serious from your user session (e.g. start a qemu vm from your user shell) it will get SIGHUP asap on shutdown, because systemd doesn't care about non service pids. but oh well.

...which is where the jokes about "systemd is good for really fast reboots" came from mostly.

Re: Why systemd is a problem for embedded Linux

#232

Post by consteval »

righthand wrote: post #147
samatman wrote: post #87

Earlier quoted context omitted.

Sugar is not, in fact, a poison. As for drugs: > Alle Dinge sind Gift, und nichts ist ohne Gift; allein die Dosis macht, dass ein Ding kein Gift ist. - Paracelsus, 1538 https://en.wikipedia.org/wiki/The_dose_makes_the_poison

Sugar is indeed poison. Personally, I like to add a bit more science and reasoning to my understanding rather than rely on quotes from someone in 1538.

Sugar is not poison. It can be, in certain situations, "bad for you". But sugar is found naturally in a variety of fruits and vegetables and has been a staple of the human diet for all of history and pre-history. There's no way to describe it as "poison".

Re: Why systemd is a problem for embedded Linux

#233

Post by bmicraft »

richardfey wrote: post #145
cedilla wrote: post #80

Earlier quoted context omitted.

Okay, I'll bite. What kind of problems do you have with the part of systemd that replicates sysvinit /every other day/?

My most common issues with systemd are related to those long timeouts when something at boot/shutdown is not working as intended, and unexplained/unexplainable changes to the order of boot of some components. For the former I have given up playing whackamole with all the timeouts you need to reconfigure, for the latter I didn't even try because I know that there's something peculiar about my setup that will never wor…

    /etc/systemd/{user,system}.conf.d/dont-wait.conf:
    [Manager]
    DefaultTimeoutStopSec=5s
There, done. That's all the timeouts you'll ever need. Go and complain to your distribution they are setting the wrong defaults, even desktop environment(s) already recommend[1] setting it to a low value.

You can stop hating on systemd now, everything you needed was in `man systemd-system.conf` all along.

[1] https://community.kde.org/Distributions/Packaging_Recommenda...

Re: Why systemd is a problem for embedded Linux

#234

Post by kaba0 »

1oooqooq wrote: post #231
kaba0 wrote: post #186

Earlier quoted context omitted.

It mandates strict session termination, unlike the unsustainable wild west approach of older Unix systems. Proper resource deallocation is crucial for modern service management. When a user exits without approval of "lingering user processes," all their processes should be signaled to quit and subsequently killed.

i think the "unsustainable wild west" of sending sigterm, waiting and sending sighup was very good because it was adaptable (you were on your own if you had non standard stuff, but at least you could expect a contract) Nowadays if you start anything more serious from your user session (e.g. start a qemu vm from your user shell) it will get SIGHUP asap on shutdown, because systemd doesn't care about non service pids.…

The old way has literally no way to differentiate between a frozen process and one that just simply wants to keep on running after the session's end, e.g. tmux, screen.

It's trivial to run these as a user service, which can linger afterwards. Also, systemd has a configurable wait time before it kills a process (the "dreaded" 2 mins timer is usually something similar)

Re: Why systemd is a problem for embedded Linux

#235

Post by consteval »

egorfine wrote: post #199
RandomThoughts3 wrote: post #197

Earlier quoted context omitted.

> with hate to the unix philosophy It's a suit of a tools each doing one thing and communicating together via a message bus. How exactly is that hating the "unix philosophy" whatever that means? From where I stand, it's extremely close to the way Unix has ever done things. The design is even directly lifted from the boot system of a certified Unix.

To me it looks exactly like ann opposite of suite of independent tools.

Okay. How? They're all individual binaries that just happen to use the systemd name. You realize systemd isn't just one big program, right? It's like 30 programs, all independent of each other, with integrations to other programs.

Re: Why systemd is a problem for embedded Linux

#236

Post by consteval »

felixgallo wrote: post #20
colonwqbang wrote: post #13

This is anti-systemd FUD. Implying that applications which work without systemd are going to stop doing so. Suggesting that Linux distributions adopted systemd because it's good for distributors and not because users actually want it. We are "forced" to use systemd's udev implementation. Please.

All of those things are trivially true. What are you disagreeing with?

Except none of these are true, they're just things people have made up to conceal the fact they oppose systemd for ideological reasons. There's little to no technical arguments against systemd - it's fast, much more robust than what came before it, and services 99% of usecases.

Users DID want systemd. Ask any sys admin, most much prefer systemd.

Also systemd doesn't "force" anything. Most distributions don't even ship all systemd projects, just a couple.

systemd-init IS small. The idea that systemd is a big ole monolith is just not true, and one glance at the git repo reveals that.

Re: Why systemd is a problem for embedded Linux

#237

Post by bmicraft »

oguz-ismail wrote: post #225
mananaysiempre wrote: post #213

Earlier quoted context omitted.

> Windows 11 boots in 5 seconds on my laptop Try measuring a reboot instead. On modern Windows versions with “fast startup” enabled, the “Shutdown” button is a lie: it logs you out and hibernates the system instead of actually shutting it down. (This is important if you dual boot, because it means you can’t safely access the Windows partition in the interim.)

> the “Shutdown” button is a lie: it logs you out and hibernates the system instead of actually shutting it down I'm okay with that. How do I enable this on Ubuntu?

Are you seriously complaining right now that systemd doesn't have a specific feature no other init for linux has either, while at the same time complaining it is too complicated and does too much stuff?

Re: Why systemd is a problem for embedded Linux

#238

Post by jcalvinowens »

blueflow wrote: post #176
jcalvinowens wrote: post #67

Earlier quoted context omitted.

> That "occasional weird problem" is because systemd is not designed to be used with other software. That's not true, systemd has an explicitly documented and supported initrd interface: https://systemd.io/INITRD_INTERFACE/ It's actually really easy, there's rarely a reason for the initrd to be more complex than a single 50-line busybox script on an embedded device with built-in drivers.

"really easy" except for the hotplug events that don't get to systemd and cause your problem.

I got an immediate answer with a solution from the upstream developer when I asked about it: I can't imagine how that could have been easier to solve. And it was also trivial to hack around by leaving the entry out of fstab and mounting it in a script.

Re: Why systemd is a problem for embedded Linux

#239

Post by egorfine »

consteval wrote: post #235
egorfine wrote: post #199

Earlier quoted context omitted.

To me it looks exactly like ann opposite of suite of independent tools.

Okay. How? They're all individual binaries that just happen to use the systemd name. You realize systemd isn't just one big program, right? It's like 30 programs, all independent of each other, with integrations to other programs.

I believe they were not created to solve real problems. No one wanted a cron replacement, really.

Thus they are created out of political or ego reasons.

Re: Why systemd is a problem for embedded Linux

#240

Post by 0xbadcafebee »

pwg wrote: post #123
thnkman wrote: post #109

Earlier quoted context omitted.

Where have you heard that Slackware will be using systemd next release? I have been using slackware for years, and this is news to me.

There's nothing named "systemd" in the FILE_LIST [1] for Slack64-current (which is what eventually becomes "the next release" at the appropriate time. So it would seem the GP has been taken in by some rumor somewhere. [1] https://ftp.ussg.indiana.edu/linux/slackware/slackware64-cur...

I thought I saw in the last release a note that the next one would come with systemd. It could be I hallucinated it. Maybe I'm becoming a real LLM!
Post reply on HN