Debian Developer Resigns From The Systemd Maintainership Team

[prodigy_]

It was pretty obvious that systemd adoption meant the end of Debian as we knew it.

And here we go. It's hardly surprising that nobody wants to deal with toxic waste like systemd. (I mean nobody wants to do it for free - so don't bring Red Hat, Canonical, SUSE etc. here.)

[computerquip]

It was pretty obvious that systemd adoption meant the end of Debian as we knew it.

And here we go. It's hardly surprising that nobody wants to deal with toxic waste like systemd. (I mean nobody wants to do it for free - so don't bring Red Hat, Canonical, SUSE etc. here.)

This is not even a fucking problem with systemd. It's a problem with how Debian is organized. No other distribution that is adopting systemd is going through the same issues. What is going through your head? Explain.

[Gusar]

...you can write pkill -9 in the script

You're not seriously suggesting putting pkill -9 into a script as a valid, robust solution. 0_0

sysvinit's init can start and respawn anything you tell it to in inittab (man inittab)

And no one uses that (except for getty), because it's way too crude. In fact, daemons were made to double-fork to get away from sysvinit. With systemd though, you can configure whether a service should restart at all, the interval between restart attempts, and maximum attempts. So that, if a service has become so b0rked that it crashes right after restart, systemd will attempt to restart it the configured number of times, then leave it alone (or, if configured, perform some action).

When will you stop with this "everything has a trivial solution" shtick, when those "solutions" don't at all reach systemd's configurability and robustness? Certain things might be possible, but definitely not a trivially as you're always trying to portray it, and no one has done it in such a well integrated manner than systemd did. This reminds me, how's that prototype distro I mentioned in the other thread coming along?

[gens]

You're not seriously suggesting putting pkill -9 into a script as a valid, robust solution. 0_0

And no one uses that (except for getty), because it's way too crude. In fact, daemons were made to double-fork to get away from sysvinit. With systemd though, you can configure whether a service should restart at all, the interval between restart attempts, and maximum attempts. So that, if a service has become so b0rked that it crashes right after restart, systemd will attempt to restart it the configured number of times, then leave it alone (or, if configured, perform some action).

When will you stop with this "everything has a trivial solution" shtick, when those "solutions" don't at all reach systemd's configurability and robustness? Certain things might be possible, but definitely not a trivially as you're always trying to portray it, and no one has done it in such a well integrated manner than systemd did. This reminds me, how's that prototype distro I mentioned in the other thread coming along?

the display manager is restarted this way...

and no, it's not "too crude" when it is used as intended
i already said that blindly restarting every program that fails is a Bad Thing

do you even know the context ?
and why couldn't you put pkill -9 in a script ?
it was a complaint by the other guy
and it is after all how systemd handles shutdown (that's why it's so fast, at least used to be)

and yes, everything has a trivial solution when you are working with linux
when you are working with systemd then, in cases like a web server, you have to resort to ugly hacks (as shown above)
and i told you that you should not make temporary hacks permanent

[Gusar]

and yes, everything has a trivial solution when you are working with linux

Where's your prototype distro then? Stop with the big talk and show some proof already.

[gens]

Where's your prototype distro then? Stop with the big talk and show some proof already.

what prototype distro ?
i never said i'd do that

if you want a working example, look at any older or non-systemd distro out there
the internet has been running on linux (and bsd, to be fair) for decades now, without much downtime...

where did you get that from at all ?

[Gusar]

what prototype distro ?
i never said i'd do that

Of course you didn't. Because substance, rather than talk, is apparently too much for you. So basically, all your posts are just noise.

if you want a working example, look at any older or non-systemd distro out there

No, those older non-systemd distros don't provide nearly as much as systemd can. I even posted about one small thing in this very thread - querying service status. There's a lot more than that.

So, try again. And not the same blah blah again, but something with substance.

[gens]

Of course you didn't. Because substance, rather than talk, is apparently too much for you. So basically, all your posts are just noise.

No, those older non-systemd distros don't provide nearly as much as system can. I even posted about one small thing in this very thread - querying service status. There's a lot more than that.

So, try again. And not the same blah blah again, but something with substance.

so i have not done something i never said id do ?
i don't know how to answer that...

i told you already that you can't know if your server (in example HTTP) is running by looking if the process is running
as the process could be hanging, making the website inaccessible

the only way to be sure is to check from a computer outside of the network
and i did write a script to do just that (so much for just talk...)

anyway
you are begining to just make me sound like i don't know what i'm talking about, despite you yourself not giving any technical knowledge at all
(no, parroting "systemd does this" is not technical knowledge)
so much for this talk, i won't reply to you anymore
have fun

edit:
it's not good to send hate to people you don't know
that includes systemd devs

[niner]

It was pretty obvious that systemd adoption meant the end of Debian as we knew it.

And here we go. It's hardly surprising that nobody wants to deal with toxic waste like systemd. (I mean nobody wants to do it for free - so don't bring Red Hat, Canonical, SUSE etc. here.)

Nobody? So what about Arch Linux, CoreOS, Debian GNU/Linux, Fedora, Frugalware Linux, Mageia, NixOS, OpenELEC, openSUSE or Sabayon Linux? All volunteer driven distributions and all use systemd.

Yes, systemd adoption seems to mean the end of Debian as we knew it. Because systemd brings out sociopaths who even threaten with physical violence against volunteers who work on systemd integration. By giving these sociopaths a forum and power, Debian has lost lots of credibility and much of its good reputation.

Even if systemd opponents have had some real arguments, they lost all credibility by not distancing themselves from those sick individuals that contribute nothing but personal attacks, conspiracy theories, threats and mumbo jumbo about philosophies.

[oleid]

and yes, everything has a trivial solution when you are working with linux
when you are working with systemd then, in cases like a web server, you have to resort to ugly hacks (as shown above)

Nope, as I mentioned: systemd has software based watchdogs. Restarts can have a multitude of reasons:

Takes one of no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, or always. If set to no (the default), the service will not be restarted. If set to on-success, it will be restarted only when the service process exits cleanly. In this context, a clean exit means an exit code of 0, or one of the signals SIGHUP, SIGINT, SIGTERM or SIGPIPE, and additionally, exit statuses and signals specified in SuccessExitStatus=. If set to on-failure, the service will be restarted when the process exits with a non-zero exit code, is terminated by a signal (including on core dump, but excluding the aforementiond four signals), when an operation (such as service reload) times out, and when the configured watchdog timeout is triggered. If set to on-abnormal, the service will be restarted when the process is terminated by a signal (including on core dump, excluding the aforementioned four signals), when an operation times out, or when the watchdog timeout is triggered. If set to on-abort, the service will be restarted only if the service process exits due to an uncaught signal not specified as a clean exit status. If set to on-watchdog, the service will be restarted only if the watchdog timeout for the service expires. If set to always, the service will be restarted regardless of whether it exited cleanly or not, got terminated abnormally by a signal, or hit a timeout.