vote for systemd: Nay (now working but still Voting Nay)

[Jean-Marc Pigeon]

Quoting Lennart Poettering <mzerqung at 0pointer.de>:

> On Tue, 02.07.13 16:57, Jean-Marc Pigeon (jmp at safe.ca) 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
A bientôt
===========================================================
Jean-Marc Pigeon                        E-Mail: jmp at safe.ca
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">
===========================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5919 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130704/d6fe7c2e/attachment.p7s>