[systemd-devel] systemd inquiry

Colin Guthrie gmane at colin.guthr.ie
Tue Apr 10 05:57:08 PDT 2012


'Twas brillig, and Mark Hounschell at 10/04/12 13:36 did gyre and gimble:
> On 04/09/2012 08:06 PM, Colin Guthrie wrote:
> 
>>> Yep, that works. Can the NAutoVTs be set differently on a per target
>>> basis?
>>
>> Not as far as I know, but you should be able to do something similar via
>> a conflicts directive.
>>
>> e.g. if you have NAutoVTs=6 by default you can just put:
>> Conflicts=autovt at tty1.service autovt at tty2.service ... autovt at tty6.service
>>
>> This should prevent then kicking in. That said, I'm really not sure how
>> much you gain here. They are loaded on demand afterall, so it's not like
>> they are buring CPU cycles etc. Personally it doesn't seem worth the
>> bother to me, but maybe you have your reasons :)
>>
> 
> Again, thanks for the help. I do have my reasons but they are not really
> relevant. I will play with the Conflicts directive.
> 
> I am having another issue with an out of kernel "GPL" device driver not
> being available "on time" so to say. When the kernel discovers this pci
> card it loads it's kernel module and sets up the card for use. This
> takes around 15 seconds per card and there is usually 2-3 of them. When
> the card is up, running, and ready, the kernel module notifies udev who
> in turn executes a small script that creates 30 or so different device
> nodes for use with the card. This little script is not a systemd service
> nor a sysvinit script. When I use sysvinit, (maybe by luck) all this
> happens well before any app gets to run in my dedicated run-level. Using
> systemd it does not appear to. What does the udev-settle.service do? Can
> it help me here somehow or should I just assume that I will have to turn
> this script into a systemd service?


I suspect you want to wait for udev-settle.service before running
anything that needs it.

It should ensure that the udev event queue is fully processed and AFAIK,
this shoudl include your service.

Note that the default udev-settle timeout is 120s and systemd has a
higher timeout of 180s on running the unit itself. Depending on your use
case you may need to copy udev-settle.service to another unit (call it
what you want) and adjust both the Timeout value in the unit as run by
systemd and the inner timeout (as a --timeout argument) when calling
udevadm settle.

That said, systemd also has a concept of device units. You could create
a device unit that becomes ready when your udev script is run, that way
it can be used for ordering without having to run udev-settle.service (I
believe). See man "systemd.device"

You can order your device unit "Before=getty at tty1.service" or similar
such that the login prompt will only appear when the devices are ready.
Of course depending on how many devices you have you may need to create
several instances of them linked in your test.target.wants directory.


You certainly do not need to turn the script which is run by udev into a
systemd service.

HTHs

Col




-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/


More information about the systemd-devel mailing list