[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