[PATCH 0/3] less: display ANSI colors with option -R
dalias at aerifal.cx
Mon Feb 3 03:22:47 UTC 2014
On Sun, Feb 02, 2014 at 08:46:44PM +0200, Lauri Kasanen wrote:
> On Sun, Feb 2, 2014, at 17:56, Rich Felker wrote:
> > > > systemd is broken by design.
> > >
> > > I did not look too deeply into its design.
> > > Unless there are serious design flaws I am not aware of,
> > > the idea per se looks sensible.
> > The idea is not sensible. If I find time I'll write a short article on
> > why for ewontfix, but it basically amounts to:
> > 1. Crash in pid #1 brings down the whole system, so it's not
> > acceptable to do anything complex in pid 1.
> I fully agree with your mail. FWIW, when I made point 1 in the past,
> their response was that since they catch all signals (including segv,
> ill), systemd will happily not crash, but go on its merry way. This of
> course completely ignores that it cannot fix whatever caused the error,
> and may go on to do wildly incorrect things due to it.
Well in principle it could re-exec itself from the signal handler, but
that brings us to my point 2: doing that is not robust. I don't even
think execve is entirely atomic with respect to success/failure at the
kernel level (e.g. it can fail to map the new VM after destroying the
old one due to resource exhaustion) but even if the kernel were
careful and allocated the new VM fully before destroying the old one
and atomically replacing it, there are fatal errors that can occur
before the program takes control after exec, at least in the
dynamic-linked case (allocation, mmap, etc. failures in the dynamic
linker). With musl we can guarantee no such prior-to-entry failures
exist for the static-linked case (except when thread-local storage is
used and allocation is needed to satisfy it), but glibc and uclibc do
not make such a guarantee as far as I know (and systemd wants to be
dynamic linked anyway).
More information about the busybox