|
|
|
| Authored by: Wol on Sunday, July 29 2012 @ 07:35 PM EDT |
Except I don't believe systemd does ANY network analysis passes - so how can it
"not do enough". The whole point of systemd is that things are only
invoked when they are requested.
Thing is with your implied dependencies - for example with systemd your mounts
*wouldn't* fail - mount would simply stall until systemd caught up with it and
started the dependencies.
Yes I think you might have to specify some dependencies - "start x before
y" - but provided the config writer hasn't messed up then it's easy to
analyse - loop through all the configs starting anything that doesn't have
unsatisfied dependencies. If you make a complete loop without starting anything
then you have a circular dependency loop and that's a bug (but a config bug, not
a systemd bug).
As for the logging, if I get right what you're saying, that's actually a kernel
problem, not a systemd problem. There is a well known multiple-cpu problem where
error messages are spread over multiple printk calls, and you can get some
really mangled messages if you are unlucky. Trouble is, the fix for that isn't
easy - most fixes seem to result in losing necessary debug info should the
system crash - exactly why you need logging!
Oh - and by the way - SysV also suffers from the problem of dependencies being
poorly specified. But it's far more of a pig to fix thanks to lots of
boilerplate code in scripts. And systemd's "start on demand" is
actually possibly LESS of a demand on the system than SysV's "start
everything at once" approach.
By the way, if linux' logging can't cope with multiple things starting at once
and flooding the buffer, that's not systemd's problem, that's a problem with
linux.
That's actually one of the things that apparently people hate about Pottering -
he seems to assume that "things should work as designed". While he has
a reputation for writing "code that doesn't work", there's an awful
lot of it that doesn't work because it is intolerant of bugs elsewhere. So his
code gets blamed for faults that have long existed but never been a problem
before - like this printk stuff in the kernel - no-one's ever cared that it's
broken before because it's never been stressed before. Now systemd is stressing
it, its failings are becoming obvious, but it's not systemd's problem to fix ...
that's why Pottering's written a new logging system - to try and fix the
existing broken system. Your comment that messages seem to go all over the place
- the console, syslog, wherever - actually LONG PREdates the appearance of
systemd.
Cheers,
Wol[ Reply to This | Parent | # ]
|
|
|
|
|
