On Fri, 03 Jun 2022 15:26:44 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>Muttley@dastardlyhq.com writes:
>> The vast majority are and anyone with even a passing knowledge of shell
>script
>> can understand them. Most admins still struggle with systemd and only know
>> a few sections of it well.
>
>About 60% are. Whether or not that's a vast majority is open to anyone's
>opinion. Someone who has only a passing knowledge of some programming
>language will be hard pressed to understand anything but the most

Someone who doesn't understand or program in shell script has no business
administering a unix box. They should go and be a click monkey admin in the
windows world.

>trivial code written in it. In a Suse init.d script, I once encountered a
>comment complaining about the need to work around a bug in another Suse
>init.d script. Fixing the bug instead apparently never crossed the mind
>of the author of the comment.

I'd have fixed it myself. Couldn't do that with a systemd bug.

>It's perfectly possible to keep init.d scripts simple and thus, easily
>modifiable. But that's something Linux distributors were never good at.

I'll give you that. But they've made even more of a hash of systemd.

Bit Twister <BitTwister@mouse-potato.com> writes:
> On 02 Jun 2022 20:47:17 GMT, John Tsiombikas wrote:
>> On 2022-05-30, Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>>>
>>> Let's make it clear; systemd (or something like it) is necessary and
>>> that is why distros bundle it and use it.
>>
>> [citation needed]
>>
>>> (The answer isn't necessarily going back to some scattered shell
>>> scripts to duct-tape everything together; that's the strawman
>>> characterization of the systemd nay-sayers as a group, even though
>>> a few do advocate exactly that.)
>>
>> I'll have my scattered shell scripts thank you very much.
>>
>> Look. The requirements of distributions do not necessarilly align with
>> the requirements of users. I'm sure random init scripts are tough for
>> distributions to automatically manage, but I as a user, don't care about
>> that. I care about how easy it is for me to manually understand and
>> manage the boot process. And for me a bunch of simple shell scripts
>> running in pre-determined order due to runlevel changes are
>> *significantly* easier to understand and maintain, and as others
>> mentioned, much more flexible to boot.
>>
>> It's the same story with the proliferation of breaking a simple
>> configuration file into a .d subdirectory with a bilion random config
>> snippets. It's all to make it easier for automated tools to manage, but
>> it's definitely much harder for users to manage manually (unless of
>> course it happens to be really humongous, which it usually isn't...).
>
> First off, I am no fan of systemd. BUT it is here to stay so learn to work
> with it.

I'm not using it privately and professionally, this is more a case of
"learn how to work around it". At the moment, this looks stereotypically
like this:

[Service]
KillMode=none
NotifyAccess=all
RemainAfterExit=no

which is autogenerated (for packages needing it) by a script I've chosen
to name poetter-em-all plus a 60 line C program which transparently
invokes the systemd start command when the start action of an init
script is executed manually. As the systemd feature set isn't capable of
supporting all of the features I need and I don't care about all of the
misfeatures I don't need, I just need it to stay out of may way.

We can read documentation, BTW. And even code.

William Ahern <william@25thandClement.com> writes:
> John Tsiombikas <nuclear@member.fsf.org> wrote:
>> On 2022-05-30, Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>>>
>>> Let's make it clear; systemd (or something like it) is necessary and
>>> that is why distros bundle it and use it.
>>
>> [citation needed]
>>
>>> (The answer isn't necessarily going back to some scattered shell
>>> scripts to duct-tape everything together; that's the strawman
>>> characterization of the systemd nay-sayers as a group, even though
>>> a few do advocate exactly that.)
>>
>> I'll have my scattered shell scripts thank you very much.
>
> Shell scripts cannot fix bad process management in the daemons themselves.
> So either process management in the daemons needs to be comprehensively
> fixed and maintained (see OpenBSD), or it needs to be removed, in which case
> you still need infrastructure such as daemontools or systemd to juggle
> processes.

[...]

> If I had more time and motivation I might try to implement a different
> compromise: introducing more sophisticated process management primitives
> directly into the shell. Job management is, afterall, a core competency of
> the shell, and despite it's innumerable problems it still excels relative to
> other languages, at least for the simple stuff.

Around the time when systemd was still being debated (ie, before its
proponents forced it into all major distributions via technopolitical
coups d'etat) an old project I had been working on was finally
discontinued and I started working on a new one. The old had a dedicated
init I wrote myself. For the new project, I said to myself "Ok, I'm not
going to do that again. sysvinit is old and crufty but I'm perfectly
happy with making it do whatever I need it to do. As an experiment,
whenever I run into another process management problem, I'll write a
small C program specifically for solving it and see how far this will
carry me."

This was 13 years ago. Meanwhile, there are 37 of these tools with a
combined size of 5355 lines of code and I haven't run into something
which couldn't be solved in this way so far.

Morale: Their are two kinds of programmers, those who create immensly
complicated programs to solve simple problems and those who strive to
create simple programs to solve complicated problems. The members of the
first group are much more admired than the members of the second.

[...]

> Success might still be contingent on fixing and complementing existing
> kernel facilities, especially if you want to achieve correctness without
> centralizing everything under, e.g., PID 1 init. (For example, process
> descriptor semantics and interfaces might not be improved.) Even systemd
> still falls short of semantic correctness as it's still technically
> susceptible to some of the same races as traditional PID files.

When I learned that systemd still uses PID files, as was only halfway
surpised. Something like "Well, why have I ever believed they to would
discontinue this habit?" :-)

On 2022-06-02, Bit Twister <BitTwister@mouse-potato.com> wrote:
>
> First off, I am no fan of systemd. BUT it is here to stay so learn to work
> with it.

The beauty of UNIX, and even more so of free software, is that I don't
have to. I can choose to never run systemd on my computers and that's
what I intend to do. No need to learn to work with shitty programs.

--
John Tsiombikas
http://nuclear.mutantstargoat.com/

In article <slrnt9kl4c.jvp.nuclear@goat.mutantstargoat.com>,
John Tsiombikas <nuclear@member.fsf.org> wrote:
>On 2022-06-02, Bit Twister <BitTwister@mouse-potato.com> wrote:
>>
>> First off, I am no fan of systemd. BUT it is here to stay so learn to work
>> with it.
>
>The beauty of UNIX, and even more so of free software, is that I don't
>have to. I can choose to never run systemd on my computers and that's
>what I intend to do. No need to learn to work with shitty programs.

Of course you can. And you do, as do I.

But that's not really what this thread is about.

--
"There's no chance that the iPhone is going to get any significant market share. No chance." - Steve Ballmer

On Fri, 03 Jun 2022 17:34:33 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>complicated programs to solve simple problems and those who strive to
>create simple programs to solve complicated problems. The members of the
>first group are much more admired than the members of the second.

So very true sadly.

Spiros Bousbouras <spibou@gmail.com> wrote:
>I wasn't familiar with this functionality. Does it offer any advantages over
>using GNU screen or script ?

It works even in early stages of boot when it's not yet possible to
log in. Used to be very helpful if the cause of the error was followed
by three pages of kenel oops and stack traces.

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834