systemd: Is it wrong?

[Alexander Boström]

Hi,

I'm a sysadmin who likes when things change for the better. I also like
systemd. Sure, I read this list and stay informed, but my employer is a
RHEL subscriber so for non-hobby purposes I only need to deal with
change every few years, which is manageable. (SSSD is a "problem" of
this kind in RHEL6, but if you actually look at it you see that it
solves real issues and has the potential to solve even more. The
alternative is stagnation.)

That said, I'd rather have the old SysV scripts than unit files created
"in anger", because yes, the latter will be ugly and annoying to use.

But the goal has to be a set of nice and clean unit files, so please try
to work on that? I've yet to see any sound technical argument about why
it couldn't be done.

I'm sceptical of Jóhann's FOO="foo=4711" solution. (Nothing to do with
integers vs. strings, btw, non-set shell variables has always had a
default value of the empty string.)

Perhaps a better approach is either to use a little helper script that
calls sysctl and modprobe if the variables are set (exactly what the
SysV script does) or even better, move this logic into rpc.statd itself
(reimplement in C).

Maybe if you move it into rpc.statd then module autoloading becomes
possible too, which simplifies things further?

To me, the thing about conditionally starting the GSSAPI stuff sounds
like a job for socket activation, but that's just a guess.

/abo