Systemd, I fucking love you. When a service crashes, let's just keep it turned off, don't restart it on your own, no need for that. That's what statefulness means, right Poettering? Such an amazing init, well worth the quarter GB of code or however much it is now. And yes I know that the unit files can be edited to achieve that. But seriously, should I really have to do that for each individual service on each individual box, because systemd can't do it on its own?

That feeling when an init system is (relatively) decent at doing everything else it absorbed into itself, yet fucking sucks at being.. a goddamn init. Good game Poettering. Such an amazing init system you wrote there. God fucking dammit man.. how hard can it be? There's OpenRC and BSD's /etc/rc.conf which are literally mere kilobytes of scripts and they do both statefulness and parallelization (in case of OpenRC anyway) *excellently*. Yet systemd can't even do that much? Awesome. Great init. I love it.

Come fucking on man...

poetterig must be one of the most hated coders ever...

Read your first sentence and thought "wtf happened to Condor??? Who hit his head that hard? Can't be another bar fight, can it?" :)

I wonder which is happening first: systemd being replaced by smth else or people eventualy giving up and finding their peace w/ sysD 😀

I don’t think it’s fair to expect an init system to handle that for you without explicitly telling it to. However, I do agree that systemd is way too large and has a lot of room for improvement.

systemd really sucks. Same here.

@erandria On LKML, sure. There are people crazy to send death threats. Cyber bullying over code they probably haven't read.

Only had a spurious encounter with systemd which went OK. Can't say much about the other init systems, but my stance is (still waiting to be disproved): All code is shit and sucks to work with. Beauty can only be found in code that isn't used.

Systemd is everything,
A boot-loader,
A network-manager,
A dns-resolver...
But definitely not a good init.
Which makes me question why this peace of shit found its way into nearly all linux-distros.

OpenRC and Runit are the, by far, better alternatives.

You can change the systemd policy yourself.

I have to learn a lot! I thought systemd was the best. Now I have to revisit old init systems

Maybe adding `Restart=on-failure` can restart your service (if it fails) but yes as you mentioned you have to change that in each and every service files (or at least in some where you need) and then reload the daemon.

@hash-table I honestly didn’t know till now how big systemd installation was.

But if that rumour is true let’s all switch to runit or upstart. I see one of my favourite distro uses runit

@hash-table Hmm 🤔! Interesting. So I would suggest maybe VoidLinux could help but that might be a lot of change from archlinux also relatively support will be less.

The Tragedy of systemd: https://youtube.com/watch/...
to make it short: he shows what behind the rants about systemd really are and he isnt even a linux user. He's a bsd dev. The first third he goes into the history of init-systems, they are important to understand the rest.

@stop whish I could ++ that more.

>has never had an issue with systemd
>has been annoyed at how fast services come back up when they crash due to the logs being wiped out after the restart

can't relate

@Linux that's my point. Yes I could change these things, but there's no reason that I can tell for systemd to not default to this. And having to manually edit systemd's behavior doesn't scale up well at all. I don't want to have to do this on 500 hosts.

What's more, systemd is aware of state (despite it clearly not acting like it is), and it has implemented a way to specify how many times a unit has to be attempted to get (re)started.

If a unit fails, generally I think there's 2 ways that could happen. First is operator error - a misconfigured unit. Second is the process crashing. Now there is an argument to be made about "init doesn't know which one of the 2 that would be". But if a process crashes, chances are that a restart will bring it right back up again when it's attempted. And when it's an error in the unit file, chances are that it will not restart until the unit file is corrected, so it will hit that restart limit (I think default is 3 or 5 times, not sure). So I don't see any reason for systemd to not make this behavior a default.

Try monit it handles this really well plus it can alert you if it happens.

Well, if it failed it will fail again or unable to start, so why would systemd do anything about it?

@mundo03 Restarting the unit without changes brought it up again. If it wouldn't be able to restart after a crash for some reason, I agree, system should try a few times and stop after that. On a service that just crashed and can be restarted no problem like this here case however, it should.

@Condor bit it failed for s reason, restarting it like that might mean it will fail again.

No?

@mundo03 programs do crash at times unfortunately ¯\_(ツ)_/¯ that's why init systems that just bring up a service and then walk away don't work. Especially when a server remains up for weeks, months or even years at a time, programs crashing isn't an exception, it's common. I guess it's kind of like with memory where ECC is pretty much a necessity in servers, because it will inevitably get corrupted over time.

@Condor makes sense, I trust you