[systemd-devel] systemd inquiry

[Mark Hounschell]

On 04/23/2012 08:33 AM, Mark Hounschell wrote:
> On 04/22/2012 06:54 AM, Lennart Poettering wrote:
>> On Fri, 13.04.12 13:37, Mark Hounschell (markh at compro.net) wrote:
>>
>>>
>>> On 04/12/2012 08:25 AM, Mark Hounschell wrote:
>>>> On 04/11/2012 05:12 PM, Kay Sievers wrote:
>>>>> On Wed, Apr 11, 2012 at 22:44, Mark Hounschell<markh at compro.net>
>>>>> wrote:
>>>>>
>>>>>> Same thing. About 20 seconds after reaching the target, the device
>>>>>> entries
>>>>>> show up.
>>>>>
>>>>> Does that block or return immediately?
>>>>> rmmod<driver>;
>>>>> modprobe<driver>; time udevadm settle
>>>>>
>>>>> Your driver creates the stuff async?
>>>>
>>>> After booting up to graphical login:
>>>>
>>>> rmmod dgdm
>>>> modprobe dgdm ; time udevadm settle
>>>>
>>>> real 0m0.107s
>>>> user 0m0.000s
>>>> sys 0m0.000s
>>>>
>>>> modprobe blocks until the process has completed.
>>>>
>>>>
>>>> It appears, by watching the boot screen, when using sysvinit the boot
>>>> process pauses at a certain point until this has completed. It doesn't
>>>> stop as soon as it starts, but it does pause nun the less. Using
>>>> systemd
>>>> it does appear to.
>>>>
>>>
>>> Correction: Using systemd it does NOT appear to.
>>
>> On a systemd system that lacks udev-settle in the boot path we do not
>> wait for any module to finish initialization at boot. This makes things
>> fast and clean but will not work if code that initializes later is not
>> capable of dealing with hardware being added at runtime.
>>
>
> Does putting the Requires and After for udev-settle in the target file
> cause it to be "in the boot path"?
>
>> If you enabled udev-settle we will delay boot for a certain amount of
>> time until all drivers that have been queued to load are finished (or a
>> timeout elapses). This is only necessary if your sw is incapable of
>> properly dealing with hw that shows up dynamically.
>>
>> Lennart
>>
>
> The cards are detected at boot time, the driver loads, starts the cards
> running (this is what takes so long), creates the device entries, then
> leaves it's init routine.
>
> Does not the following "lcrs-host.service" service file cause
> udev-settle to do it's thing on boot?
>
>
> [Unit]
> Description=LCRS host
>
> Requires=udev-settle.service
> After=udev-settle.service
>
> [Service]
> Environment=TERM=vt100
> ExecStart=/sbin/qlogin /dev/ttyS0 root --homedir=/lcrs --noutmp
> --command=/bin/bash --login -c /lcrs/sh.lcrs_host
> Restart=always
> RestartSec=3
>
>
> This is my target file.
>
>
> [Unit]
> Description=LCRS run-level-4 target
>
> Requires=syslog.target
> Requires=udev-settle.service
>
> After=syslog.target
> After=udev-settle.service
>
> Before=getty at tty1.service
>
> Wants=getty at tty1.service
> Wants=getty at tty2.service
> Wants=syslog.service
> Wants=udev.service
>
> Conflicts=getty at tty3.service
> Conflicts=getty at tty4.service
> Conflicts=getty at tty5.service
> Conflicts=getty at tty6.service
>
> Wants=lcrs-host.service
>
> AllowIsolate=yes
>
>
> Once in a while, it actually does wait and everything works as I would
> expect??? But that's rare.

Should I file a bug report somewhere on this??

Mark