Re: piece of mind
On Tue, Oct 21, 2014 at 04:23:39PM -0700, Cameron Norman wrote:
> El mar, 21 de oct 2014 a las 7:03 , Josselin Mouette
> <joss@debian.org> escribió:
> >The Wanderer <wanderer@fastmail.fm> wrote:
> > This is the problem. The init system should not be
> >providing "features"
> > which other software might, post-boot and pre-shutdown,
> >want to make use
> > of. (AFAIK sysvinit never did, and most - possibly all? -
> >of the other
> > init-system candidates don't either.) Such features should
> >be provided
> > separately, independent of what may happen to be running
> >as PID 1.
> >
> >These features cannot exist separately. Quoting the systemd position
> >statement:
> >
> >[…] while it is true that a handful of trivial interfaces are not
> >really
> >related to systemd (and could be split out if needed), most of these
> >features cannot be implemented without close integration to PID 1.
> >It is
> >not possible to split the system cgroups arbitrator from the process
> >which starts services and sessions in cgroups. It is not possible to
> >ensure the relation of a log to a service if you do not have awareness
> >of how the service was launched. Et caetera.
>
> Upstart can launch processes in cgroups using cgmanager since
> version 1.13. Few things are truly impossible with programming, and
> making certain functions be implemented independent of or outside of
> PID 1 does not come close to impossible.
>
> Also, I do not understand the log statement. Once again, Upstart can
> hook up a job's stdout/err to a file in /var/log/upstart/, but I am
> not exactly sure what was being said so maybe I missed the point.
[Speaking as systemd developer] the way I understand the argument,
this is also a no-no, because the init system should not interfere with
logging in any way. So upstart violates this requirement too.
OTOH, just intercepting writes to stdout and stderr is not enough.
A lot (most?) daemons use syslog(), and journald uses the knowledge
of how PID1 arranges the cgroup layout to relate PIDs back to units
and annotates messages with service information. Without this integration
things like 'journalctl --unit=' would not work.
BTW., I've always wondered, but been to lazy to properly investigate.
how does upstart deal with rotation of those log files in
/var/log/upstart? Is it necessary to restart a daemon if it logs too
many lines?
Zbyszek
Reply to: