On 07/02/2013 04:08 PM, Jean-Marc Pigeon wrote:
I was not expecting to have it fully working at the first attempt in my
own container design,
Would you be willing to provide some details about your container
design? Ideally including the code to allow others to reproduce the
problems you saw.
Have you seen these recommendations?:
http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
but I was expecting systemd (using systemctl very detailed status) to give
me a very good insight about issues which could occur.
The real goal was to learn how to use systemd components to diagnose an "in
trouble" real system, a kind of flight simulator exercise, so that we
would be ready in the future to do quick diagnosis if one of our server
in a rack had trouble to boot or reboot with EL7.
Interesting excersise, but I am afraid by running it in a custom
container design and running under a host that itself is not using
systemd you uncovered an entirely different class of problems than what
can happen when running it on the host.
This small exercise turned out very ugly very quickly, I worked very hard
trying all the tricks and bypass I could think about to collect data. To
my dismay I
was unable to get a predictable behaviour, nor reliable data from
systemd, even in the emergency.service mode.
After a while, I was forced to face it, systemd won't help me, not even
start the system in a minimal mode,
I was not able to go beyond kernel level with systemd in control,
services started were a total mess and container was totaly lock up,
with no exploitable data provided.
Not sure how much of it relates to container environments, but have you
seen this?:
http://freedesktop.org/wiki/Software/systemd/Debugging/
My first goal when debugging issues like this would be to make sure I
can see the debugging output of systemd itself (i.e. with log_level set
to debug and log_target to something I can read - probably "console" in
the case of a container).
(Quickly: we had interesting situation within the noisy and cold server
room using the emergency.service console
such as:
$ systemctl start systemd-journald.service
--> "unable to comply!" a dependency job for systemd-journald.service
failed, see journactl -xn.
This is when logging to "kmsg" (the dmesg buffer) or "console" can
really help find out the problem.
I ended up asking myself 'what part of this puzzle am I missing?',
I digged around in Google about systemd and I was stunned by results, I
found
my concerns were already expressed multiple time with more talented
words than mine
and this as early as 2010. Since that time it is my understanding
systemd continuously try to resolve problems
by increasing its complexity and extending its dependencies and its
centrality.
this is wrong, this is very very wrong.
A program as complex as systemd can't be a mandatory PID1 in an open
environment as UNIX.
From the above paragraphs I get the feeling you may be missing the fact
that not all of "systemd" runs in PID1. There are more components in the
"systemd" project, such as journald, logind, ... - they run as separate
processes. There is some ambiguity when talking about "systemd".
Sometimes it refers only to the service manager (PID1), and sometimes to
the whole suite.
BTW and to go a little bit beyond the systemd case, since 1991,
FC18 is the very first distribution I was NOT successful in
installing on a plain hardware
I heard F19 was released today with an improved Anaconda :-)
Michal
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
