On 09/19/2014 07:34 PM, Joel Rees wrote:
On Sat, Sep 20, 2014 at 1:36 AM, T.J. Duchene <t.j.duch...@gmail.com> wrote:
I do not understand something that has been bugging me for a while and I'd
like to ask the many minds of the list why this would not be possible,
especially since Debian has some of the best Linux people out there, who
have worked on the system for 20+ years.
Why is it not possible to create a completely generic shell script -
basically ala SysV that can parse systemd config files for those use cases
where Systemd is undesirable?
Shell scripts can parse simple configuration files, in part because
simple configuration files tend to either directly use the shell
syntax (a custom the systemd crew explicitly eschews) or have a form
that can be massaged, via awk, sed, or m4 scripts into shell syntax.
(Somewhat simplifying things here.)
Systemd config files are not simple.
How about giving the parsing job to init? I hear it will soon be out of
a job and looking for work.
It violates the "do one thing" idea but for a good cause, I think.
You could start here:
https://github.com/intgr/systemd/blob/master/src/shared/conf-parser.c
A parser lib could be used by other system packages, like cggroups. It's
not exactly what the OP proposed, but I don't see any problem with the
basic idea.
That would not prevent using lex/yacc to define a parser and writing
our own parser in C, but, the configuration files are a relatively
minor part of the problems with systemd.
systemd was billed as an init replacement, and sysvinit script
maintenance was cited as a reason for the change, so there's that.
What systemd does is basically a generic process of reading parameters from
a file and using them to start a service.
If that were true, I don't think anyone would be fussing about systemd at all.
That is, if systemd were just a generic service starter, it would be
keeping its fingers out of login, file permissions, and all sorts of
other stuff that it gets itself entangled with.
Like kbd and ntp, and more to come, I'm sure. As far as can tell,
configuration is the only thing that (weakly) ties them to systemd.
It would be properly
delegating, as the pid 1 process must, if you want to keep a system
stable and secure in the long term.
I am not a systemd expert but supporting the systemd configuration
format does not preclude a minimal init, as far as I can tell.
Granted, this approach would have
the benefits that systemd has, but the concerns about systemd being too
opaque or monolithic could be almost mitigated.
If your assumptions were correct, mitigation would be meaningless.
systemd would be small and simple enough that monolithic and opaque
would not be terms that would apply.
The remaining concerns such as login and so on can be addressed separately.
Those remaining concerns are where the bulk of the problems lie.
Having a systemd parser could give the threatened utilities more reason
to be maintained.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/541dd508.6090...@ix.netcom.com
