[systemd-devel] systemd inquiry

Mark Hounschell markh at compro.net
Mon Apr 23 05:33:54 PDT 2012


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.

Regards
Mark


More information about the systemd-devel mailing list