hello,
 

Citando Dimitris via Dng <dng@???>:

> On 5/17/20 12:04 AM, tuxd3v@??? wrote:
>> But is a major flaw, being it a init system for a operating system, and
>> not beign able to run shell scripts( systemd has also this limitation.. )..
>
> you're right about s6, but wrong about systemd.you can run shell
> scripts with that bloated beast.

What  I meant was that..you know..
systemd or S6 is not shell built-ins/ Environment  aware.

You can execute commands that are operating system available..
I believe that you can also do the same with S6,
But you can't use direct shell scripting language to be executed by
systemd, or by S6( the proper developer of S6 spoke about that in the
Devuan conference.. ).

They could had done it Shell aware, and substitute the crapy unit
files with direct shell scripting,
Which is a lot more natural( as it is the system language.. ), and
reduce the amount of files, for the same thing..

Moreover, a "called motive" for the systemd existence, as I recall it,
"terminate the amount of files or symlinks "madness" that goes on
SysVInit"..??anyone remember?
I do..

The result...
They ended creating a ton of symlinks more, plus the need of 2 files
for each service o_0..using a closer method like is used in SysVInit
with symlinks to the deamon..
In fact the number of symlinks that exist in systemd is *insanely*
high, a lot but a lot bigger than in SysVinit..they are hidden..

They fork and exec what is given in the command, so for systemd, the
thing get even uglier..
You need to create a Service unit file, that is not shell aware, and
then you need to create the REAL SHELL SCRIPT to pass to that file, to
be executed,
And then prepare it to run accordingly..insane!

if you think that systemd is shell friendly,
Test it, :)

You can start by a command that could be very basic like:
'A=0;WHILE READ LINE;DO ECHO $A:$LINE;LET ++A;DONE < /ETC/FSTAB'

And we doesn't even started to speak about Environment variables( and
its propagation inside the same namespace )..
That is another atrocity that could had been prevented was it shell
aware from the beginning, because you can set or unset variables in
shell scripting when you want..

Let's take for example a SAP service,
That at least will take 7 different users, several databases( at least
2 ), for several Java Installations( administration/ operators, etc )..
To Launch a service like this with systemd, is madness, the amount of
environment variables are tons of them, the users are independent,
will you put all environment variables in the same place( Shared )?
But that will destroy completely the idea of roles separation,
security reasons..

I'am not saying that it is not impossible but you will start to mix,
or share things, destroying your initial goal of having all services
separated and communicating only via network/shm..
 

So long story short,
you can fork&exec *only*, you don't have the shell awareness.. :)
Ofcourse if you only have basic services running, like ntp, stmp,dhcp,
etc, its peanuts, anything can do the job..but for servers were you
have a complex setup the problems start to be noticed..

Its my believe that systemd, as a project, started with the desktop
Idea in mind, because its not designed with servers in mind..

You can look at the last disaster "homed"...
Even for desktop is terrible, you cant even run services when the
keyboard is locked...crazy.. :D
It has a similar behaviour as with MS Windows( no surprise, as the
developers that were developing it, had not real experience with unix
before, but with windows they had plenty.. )..