On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote:
Tim Waugh wrote:
> Oh, I just noticed this:
>
>
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa
> tion "Since Fedora currently doesn't want any services to do on-demand
> loading, all socket activated services must autostart."
What the heck?! We're disabling systemd's main feature there, aren't we?
Wasn't the main design concept behind systemd the observation that
everything can be parallelized most effectively by on-demand activation?
Why is bootup speed so important that init now has become network aware? Process 1
gets special protection from the kernel. You cannot kill it. If there is any mistake
in its code, then you have an unkillable all powerful process that might do rogue
things. It almost sounds like this is reinventing Xinetd - except its not as feature
rich as xinetd.
We had a lot of problems with xinetd over the years. For example, if it listens for a
connection that the service must accept and then the service fails before it can call
accept, xinetd will spin in a tight loop because the the listen socket is readable and
the service is not calling accept.
Then lets look at the accept option. If systemd accepts a connection and passes it to
a child process, do you now support tcp_wrappers so that you deny the connection
before starting the child? That would mean any flaw in tcp_wrappers now is part of
process 1 which has special protection from the kernel. How do you limit the number of
children? Xinetd grew all these features because of security problems. Xinetd had many
bugs because of these features.
I personally think systemd's configure should have an --enable-networking. I think
this
should be turned off. A network aware init could be internet worm material since you
cannot kill process 1.
-Steve