Quoting Lennart Poettering <mzerqung@xxxxxxxxxxx>:
On Tue, 02.07.13 16:57, Jean-Marc Pigeon (jmp@xxxxxxx) wrote:As expected the problem stand on a very small detail (within /etc/fstab)
Note that in a systemd world fstab shouldn't really list any of the virtual file systems like procfs, sysfs, devpts, /dev/shm, unless you have specific mount options that need to override the defaults. Also, the root file system doesn't need to be listed. It is hence a good idea to leave fstab out entirely if you run things in a container.
I beg to disagree, As I want to keep the container as close as to a pristine installed distribution and as /etc/fstab is part of it once installed, fstab must be present in the container.
The fact that the line just below says, "Please see journal" but journal is not available (empty) just compound the effect.How did you access the journal? The journal is actually available pretty much all the time. It logs to /run as long as /var is not there, to make this work (very much unlike classic syslog, btw).
Just reporting observation. there is condition where you have ""Please see journal" but journal is empty.
So, no, sorry, systemd doesn't grade "production level" (not yet? or never?).Well, as mentioned you altered the most low-level parts of the unit dep tree. So yeah, a setup like that certainly is not "production level", but that's hardly our fault.
This issue already covered in previous email,
May I propose some way to improve it. - journal should be accessible regardless of systemd status or trouble.It is. journalctl directly accesses all journal files and starts very early in the boot process, including in initrd (hint: this is *much* earlier than classic syslog). And for the time even before the journal is around, we log to kmsg (i.e. demsg).- You should have a way to proceed in a 'step by step' boot mode (avoiding in parallel fast scrolling report)systemd.confirm_spawn=yes
Didn't notice this. not sure is what I think we need. need to check.
But disabling the parallelization doesn't really work. If a service foo triggers starting of a service bar while it is starting up, and needs an answer from bar before it can proceed, how do you want to ever solve this? You need to start both foo and bar at the same time.
You need a step by step to sort out problem, instead to flush all data on the console, this give time to sysadmin to see what is happening (very good when problem is ocuuring very early in the process) In step by step I would LOCK in such situation as "bar need foo AND foo need bar", seems to me a deadly embrace situation definition, and prone to "timing issue" subtle problem. Systemd should detect such situation an complain about it. STEP by STEP mode is obviously a debug mode.
- On a more philosophical side: * linking PID1 and systemd seems to me a problem (why it is mandatory still escape me),systemd is an init system. init systems run as PID 1. This how Unix works.
Yes and I agree, But according my understanding of systemd, many function done by systemd do not need to be PID1. In fact complexity and smart action could be moved away from PID1 process keeping PID1 part, lean and simple. Such way, you could start systemd "smart and interesting" part from a shell script (which open a lot flexibility an robustness).
Bug: - After a very quick check, there is maybe a bug the way systemd is handling 'int reboot(int cmd);', I have the strong feeling systemd is not feeding WTERMSIG(status), but it is very preliminary, I could be wrong....Hmm? I cannot parse this.
OK... when within the container a reboot is issued by admin, there is a way to advise container superviser (the process above systemd), this is done by reporting a signal status. 'plain init' and 'upstart' are doing that properly, seems to me systemd is not doing it... I didn't double check this, very prelimary report. (hoping this time you can parse my explaination). Many Thanks Lennart.
Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
--
A bientôt
===========================================================
Jean-Marc Pigeon E-Mail: jmp@xxxxxxx
SAFE Inc. Phone: (514) 493-4280
Clement, 'a kiss solution' to get rid of SPAM (at last)
Clement' Home base <"http://www.clement.safe.ca";>
===========================================================
<<attachment: smime.p7s>>
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
