Post by Colin Guthrie Post by Mark Hounschell Post by Colin Guthrie Post by Mark Hounschell
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.
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
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"
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.
As Kay has replied also here, I should probably point out that this is
As your post script makes it's own devices via mknod I'm presuming udev
will be unaware of them and thus the device unit in systemd will simply
I'm sure Kay will correct me if I'm wrong here.
There are plenty other hacky ways around it tho'. e.g write a service
that runs a special sleep program (create a symlink:
/usr/bin/wait-for-special-dev-nodes to /bin/sleep) and have a unit that
Then in your script run from udev, just do "killall
wait-for-special-dev-nodes" or similar at the end to kill off the sleep
process and allow that unit to complete and any ordering related to it
to be fed back to other dependant units etc. (note that rather than make
a symlink you could likely call sleep directly and just make your kill
command a bit nicer - i.e. only kill the sleep process that is tagged
with your unit's cgroup - that's likely nicer than a symlink, but it's
harder to explain/test in an email!)
This is still horribly hacky and there are likely nicer ways to do it
(i.e. do whatever Kay says is usually a good rule here!). I just wanted
to highlight to you that there are usually ways to make old stuff at
least play semi-nicely with all the ordering and graphing goodness in
Tribalogic Limited http://www.tribalogic.net/
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/