Discussion:
systemd inquiry
(too old to reply)
Mark Hounschell
2012-04-05 17:26:46 UTC
Permalink
I'm not a systemd developer but I am trying to use it in place of
sysvinit to create a dedicated "run-level" for our application. Is this
list an appropriate place to inquire about problems I have?

Thanks in advance
Mark
Colin Guthrie
2012-04-05 21:23:15 UTC
Permalink
Post by Mark Hounschell
I'm not a systemd developer but I am trying to use it in place of
sysvinit to create a dedicated "run-level" for our application. Is this
list an appropriate place to inquire about problems I have?
Yup, ask questions here, but make sure you've read up on the various
articles and documentation and such like on
http://www.freedesktop.org/wiki/Software/systemd first :)

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/
Mark Hounschell
2012-04-09 13:59:39 UTC
Permalink
Post by Colin Guthrie
Post by Mark Hounschell
I'm not a systemd developer but I am trying to use it in place of
sysvinit to create a dedicated "run-level" for our application. Is this
list an appropriate place to inquire about problems I have?
Yup, ask questions here, but make sure you've read up on the various
articles and documentation and such like on
http://www.freedesktop.org/wiki/Software/systemd first :)
Thanks, I've read a lot but nowhere did I find pointers to do what I
need to do. So I thought I would just try to understand the process of
getting to "single-user" mode. I expected that I would be able to look
at /lib/systemd/system/single.target for a starting point but it's just
a link to /dev/null? I was then lost....

So I just created a test target that I expected/hoped would just start a
single mingetty on tty1. It did do that but I also got agettys on ttys
2-6. I also got some unwanted Console-Kit and Polkit stuff running that
I also do not want or need. Again, I'm trying to understand how to
create a run-level under which everything running is controlled by me.

My /etc/systemd/system/test.target file

Description=TEST run-level-4 target
Wants=***@tty1.service
DefaultDependencies=no
AllowIsolate=yes
[Install]
Alias=test.target


and mingetty\@.service file:



[Unit]
Description=mingetty on %I

[Service]
Environment=TERM=linux
ExecStart=-/sbin/mingetty %I
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes

Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE=
LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE=
LC_MEASUREMENT= LC_IDENTIFICATION=

KillSignal=SIGHUP

[Install]
Alias=mingetty@%I.service

Thanks for any pointers
Mark
Colin Guthrie
2012-04-09 14:30:12 UTC
Permalink
Post by Mark Hounschell
Post by Colin Guthrie
Post by Mark Hounschell
I'm not a systemd developer but I am trying to use it in place of
sysvinit to create a dedicated "run-level" for our application. Is this
list an appropriate place to inquire about problems I have?
Yup, ask questions here, but make sure you've read up on the various
articles and documentation and such like on
http://www.freedesktop.org/wiki/Software/systemd first :)
Thanks, I've read a lot but nowhere did I find pointers to do what I
need to do. So I thought I would just try to understand the process of
getting to "single-user" mode. I expected that I would be able to look
at /lib/systemd/system/single.target for a starting point but it's just
a link to /dev/null? I was then lost....
So I just created a test target that I expected/hoped would just start a
single mingetty on tty1. It did do that but I also got agettys on ttys
2-6.
Are you sure you get them? Are they not started on-demand as soon as you
switch to them? This is handled by ***@.serivce (which is just a
symlink to ***@.service by default).

Systemd handles this magically. Simply set: NAutoVTs=0 in logind.conf to
disable.

Make sure however you do enabled at least one getty manually if you do
this. I'm not sure you test.target did that. You'll want a
Post by Mark Hounschell
I also got some unwanted Console-Kit and Polkit stuff running that
I also do not want or need.
Well consolekit I agree with, but polkit is likely loaded automatically
when you start running systemctl commands. It uses polkit to decide
whether or not you are allowed to do stuff.

However, consolekit is likely started as a consequence of logging in.

Chances are you have some pam modules (i.e. pam_ck_connector) in
whatever pam config you're using to login.


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/
Mark Hounschell
2012-04-09 16:40:31 UTC
Permalink
Post by Colin Guthrie
Post by Mark Hounschell
Post by Colin Guthrie
Post by Mark Hounschell
I'm not a systemd developer but I am trying to use it in place of
sysvinit to create a dedicated "run-level" for our application. Is this
list an appropriate place to inquire about problems I have?
Yup, ask questions here, but make sure you've read up on the various
articles and documentation and such like on
http://www.freedesktop.org/wiki/Software/systemd first :)
Thanks, I've read a lot but nowhere did I find pointers to do what I
need to do. So I thought I would just try to understand the process of
getting to "single-user" mode. I expected that I would be able to look
at /lib/systemd/system/single.target for a starting point but it's just
a link to /dev/null? I was then lost....
So I just created a test target that I expected/hoped would just start a
single mingetty on tty1. It did do that but I also got agettys on ttys
2-6.
Are you sure you get them? Are they not started on-demand as soon as you
You are correct, they were started "on demand" when I switched to them.
Post by Colin Guthrie
Systemd handles this magically. Simply set: NAutoVTs=0 in logind.conf to
disable.
Yep, that works. Can the NAutoVTs be set differently on a per target basis?
Post by Colin Guthrie
Make sure however you do enabled at least one getty manually if you do
this. I'm not sure you test.target did that. You'll want a
Simply adding the "Wants=***@tty1.service" to the target file seems
to be enough. A link in the .wants directory doesn't seem to be needed.
Post by Colin Guthrie
Post by Mark Hounschell
I also got some unwanted Console-Kit and Polkit stuff running that
I also do not want or need.
Well consolekit I agree with, but polkit is likely loaded automatically
when you start running systemctl commands. It uses polkit to decide
whether or not you are allowed to do stuff.
However, consolekit is likely started as a consequence of logging in.
Chances are you have some pam modules (i.e. pam_ck_connector) in
whatever pam config you're using to login.
Yep, you are correct. Using sysvinit, I get the same thing.

This might turn out to be easier than I thought after all. Can you
comment on the NAutoVTs thing above?

Thanks and regards
Mark
Colin Guthrie
2012-04-10 00:06:44 UTC
Permalink
Post by Mark Hounschell
Post by Colin Guthrie
Post by Mark Hounschell
So I just created a test target that I expected/hoped would just start a
single mingetty on tty1. It did do that but I also got agettys on ttys
2-6.
Are you sure you get them? Are they not started on-demand as soon as you
You are correct, they were started "on demand" when I switched to them.
Post by Colin Guthrie
Systemd handles this magically. Simply set: NAutoVTs=0 in logind.conf to
disable.
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=***@tty1.service ***@tty2.service ... ***@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 :)

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/
Mark Hounschell
2012-04-10 12:36:04 UTC
Permalink
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?

Regards
Mark
Colin Guthrie
2012-04-10 12:57:08 UTC
Permalink
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
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=***@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/
Colin Guthrie
2012-04-10 16:33:57 UTC
Permalink
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
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"
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
likely wrong.

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
not work.

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
contains:


Type=oneshot
ExecStartPre=-/usr/bin/wait-for-special-dev-nodes 180
ExecStart=/bin/true
RemainAfterExit=true

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
systemd :)


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/
Kay Sievers
2012-04-10 13:10:18 UTC
Permalink
Post by Mark Hounschell
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.
A bit unrelated to the described specific problem above, but:

We do not support any kernel device driver which does not create the
device nodes on its own from inside the kernel. Such drivers cause
problems and will fail for various non-interesting reasons. You really
must hook up the kernel driver to register the devices with the kernel
driver-core; it's just a few lines to add.

Doing mknod() in userspace is just too fragile and does not fit into
any synchronization logic of udev or systemd, it is not even expected
to work reliably with these tools.

Kay
Mark Hounschell
2012-04-10 14:26:09 UTC
Permalink
Post by Kay Sievers
Post by Mark Hounschell
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.
We do not support any kernel device driver which does not create the
device nodes on its own from inside the kernel. Such drivers cause
problems and will fail for various non-interesting reasons. You really
must hook up the kernel driver to register the devices with the kernel
driver-core; it's just a few lines to add.
Ya, I've thought about this. We have actually converted all our drivers
to do this in kernel. This one is actually a 3rd party driver that we've
had to maintain because the original mfgr no longer does. Even though
they still make the cards. Anyway, I suspect this type of issue won't
just go away because of what your saying here so the info that Colin is
giving is very useful to me and others may also find it useful. For the
sake of myself I will be attempting to use what Colin has suggested, but
then also maybe reevaluate fixing up the driver. It just uses so many
device nodes that I would rather it all be done in user land. Earlier I
said around 30 device nodes per card but it is actually around 180 per
card with many different majors and minors. Forcing the kernel module to
implement this would for sure be a very messy thing.
Post by Kay Sievers
Doing mknod() in userspace is just too fragile and does not fit into
any synchronization logic of udev or systemd, it is not even expected
to work reliably with these tools.
I don't know what you mean by fragile but using mknod in user land has
been around in the "unix" world forever and I suspect is not likely to
just disappear from the Linux world just because systemd/udev developers
don't like it or haven't figured out what to do about it yet.

In any case I understand what you are saying and thanks.

Regards
Mark
Kay Sievers
2012-04-10 14:52:38 UTC
Permalink
Post by Kay Sievers
We do not support any kernel device driver which does not create the
device nodes on its own from inside the kernel. Such drivers cause
problems and will fail for various non-interesting reasons. You really
must hook up the kernel driver to register the devices with the kernel
driver-core; it's just a few lines to add.
Ya, I've thought about this. We have actually converted all our drivers to
do this in kernel. This one is actually a 3rd party driver that we've had to
maintain because the original mfgr no longer does. Even though they still
make the cards. Anyway, I suspect this type of issue won't just go away
because of what your saying here so the info that Colin is giving is very
useful to me and others may also find it useful. For the sake of myself I
will be attempting to use what Colin has suggested, but then also maybe
reevaluate fixing up the driver. It just uses so many device nodes that I
would rather it all be done in user land. Earlier I said around 30 device
nodes per card but it is actually around 180 per card with many different
majors and minors. Forcing the kernel module to implement this would for
sure be a very messy thing.
No, not at all.

You register cdevs (or blockdevs) in the kernel anyway, otherwise the
userspace-created nodes would not do anything when you open them. At
the very same time you register the cdev (blockdev) minor you just
register the node (with struct device) in the kernel. It's just a few
lines on top of what you do anyway.

There is no general problem to create 100s or 1000s of nodes per device.
Post by Kay Sievers
Doing mknod() in userspace is just too fragile and does not fit into
any synchronization logic of udev or systemd, it is not even expected
to work reliably with these tools.
I don't know what you mean by fragile but using mknod in user land has been
around in the "unix" world forever and I suspect is not likely to just
disappear from the Linux world just because systemd/udev developers don't
like it or haven't figured out what to do about it yet.
Sure, we have figured it out; we refuse to work around such drivers. :)

It does not matter at all what UNIX did, it did a lot of other stuff
too which makes not much sense, and it has nothing to do how
Linux/systemd/udev works today.

Sure, you can try to hack around the problem, but be aware that this
might not work as you expect, and that the core infrastructure does
not really deal with setups like that.
In any case I understand what you are saying and thanks.
Cool.

Cheers,
Kay
Mark Hounschell
2012-04-10 20:55:42 UTC
Permalink
Post by Kay Sievers
Post by Kay Sievers
We do not support any kernel device driver which does not create the
device nodes on its own from inside the kernel. Such drivers cause
problems and will fail for various non-interesting reasons. You really
must hook up the kernel driver to register the devices with the kernel
driver-core; it's just a few lines to add.
Ya, I've thought about this. We have actually converted all our drivers to
do this in kernel. This one is actually a 3rd party driver that we've had to
maintain because the original mfgr no longer does. Even though they still
make the cards. Anyway, I suspect this type of issue won't just go away
because of what your saying here so the info that Colin is giving is very
useful to me and others may also find it useful. For the sake of myself I
will be attempting to use what Colin has suggested, but then also maybe
reevaluate fixing up the driver. It just uses so many device nodes that I
would rather it all be done in user land. Earlier I said around 30 device
nodes per card but it is actually around 180 per card with many different
majors and minors. Forcing the kernel module to implement this would for
sure be a very messy thing.
No, not at all.
You register cdevs (or blockdevs) in the kernel anyway, otherwise the
userspace-created nodes would not do anything when you open them. At
the very same time you register the cdev (blockdev) minor you just
register the node (with struct device) in the kernel. It's just a few
lines on top of what you do anyway.
There is no general problem to create 100s or 1000s of nodes per device.
Yes, I understand what has to be done to the driver to make it create
it's own device nodes as I've already done the conversion on all our
other drivers I maintain. I've decided to go ahead and do the conversion
to this one also, at least for the device nodes I actually need. %99 of
them, I don't need or use. I'll post the results when I'm done.

Thanks and Regards
Mark
Mark Hounschell
2012-04-11 19:41:19 UTC
Permalink
Post by Kay Sievers
Post by Mark Hounschell
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.
We do not support any kernel device driver which does not create the
device nodes on its own from inside the kernel. Such drivers cause
problems and will fail for various non-interesting reasons. You really
must hook up the kernel driver to register the devices with the kernel
driver-core; it's just a few lines to add.
Doing mknod() in userspace is just too fragile and does not fit into
any synchronization logic of udev or systemd, it is not even expected
to work reliably with these tools.
OK, I've changed the driver such that is creates it's own device nodes
after the board is up and running. Like I said earlier, it takes a
single board 10-15 seconds to come up once the driver starts it. There
are now, no scripts required, no sysvinit, no systemd, no udev involved.

Still, when using systemd, when I get to my run-level, the application
fails because the device nodes have yet to be created. The driver is
still waiting for the boards to be ready. When I use sysvinit the device
nodes are there when I get to my run-level.

???

Regards
Mark
Kay Sievers
2012-04-11 20:02:33 UTC
Permalink
Post by Kay Sievers
Post by Mark Hounschell
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.
We do not support any kernel device driver which does not create the
device nodes on its own from inside the kernel. Such drivers cause
problems and will fail for various non-interesting reasons. You really
must hook up the kernel driver to register the devices with the kernel
driver-core; it's just a few lines to add.
Doing mknod() in userspace is just too fragile and does not fit into
any synchronization logic of udev or systemd, it is not even expected
to work reliably with these tools.
OK, I've changed the driver such that is creates it's own device nodes after
the board is up and running. Like I said earlier, it takes a single board
10-15 seconds to come up once the driver starts it. There are now, no
scripts required, no sysvinit, no systemd, no udev involved.
Sounds cool. :)

Udev and systemd are involved now, at least in a way that they see
uevents, which did not exist before.
Still, when using systemd, when I get to my run-level, the application fails
because the device nodes have yet to be created. The driver is still waiting
for the boards to be ready. When I use sysvinit the device nodes are there
 when I get to my run-level.
Try:
systemctl enable udev-settle.service

Kay
Mark Hounschell
2012-04-11 20:07:39 UTC
Permalink
Post by Kay Sievers
Post by Kay Sievers
Post by Mark Hounschell
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.
We do not support any kernel device driver which does not create the
device nodes on its own from inside the kernel. Such drivers cause
problems and will fail for various non-interesting reasons. You really
must hook up the kernel driver to register the devices with the kernel
driver-core; it's just a few lines to add.
Doing mknod() in userspace is just too fragile and does not fit into
any synchronization logic of udev or systemd, it is not even expected
to work reliably with these tools.
OK, I've changed the driver such that is creates it's own device nodes after
the board is up and running. Like I said earlier, it takes a single board
10-15 seconds to come up once the driver starts it. There are now, no
scripts required, no sysvinit, no systemd, no udev involved.
Sounds cool. :)
Udev and systemd are involved now, at least in a way that they see
uevents, which did not exist before.
Still, when using systemd, when I get to my run-level, the application fails
because the device nodes have yet to be created. The driver is still waiting
for the boards to be ready. When I use sysvinit the device nodes are there
when I get to my run-level.
systemctl enable udev-settle.service
I should enter this command then reboot?

Mark
Kay Sievers
2012-04-11 20:17:41 UTC
Permalink
Post by Mark Hounschell
  systemctl enable udev-settle.service
I should enter this command then reboot?
Yeah, there is a chance, that the uevents will block this service then.

Or just make your application depend on that service, then it's pulled
in automatically and does not need to be enabled.

Not that I think of it, it might be needed anyway to order the app
after this service to have the right effect.

So add a: Requires=udev-settle.service and After=udev-settle.service
to your applications service file.

Kay
Mark Hounschell
2012-04-11 20:44:59 UTC
Permalink
Post by Kay Sievers
Post by Mark Hounschell
Post by Kay Sievers
systemctl enable udev-settle.service
I should enter this command then reboot?
Yeah, there is a chance, that the uevents will block this service then.
Or just make your application depend on that service, then it's pulled
in automatically and does not need to be enabled.
Not that I think of it, it might be needed anyway to order the app
after this service to have the right effect.
So add a: Requires=udev-settle.service and After=udev-settle.service
to your applications service file.
Same thing. About 20 seconds after reaching the target, the device
entries show up.

Mark
Kay Sievers
2012-04-11 21:12:26 UTC
Permalink
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?

Kay
Mark Hounschell
2012-04-12 12:25:32 UTC
Permalink
Post by Kay Sievers
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.

Regards
Mark
Mark Hounschell
2012-04-13 17:37:53 UTC
Permalink
Post by Mark Hounschell
Post by Kay Sievers
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?
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.

Thanks
Mark
Mark Hounschell
2012-04-17 12:48:18 UTC
Permalink
Post by Mark Hounschell
Post by Mark Hounschell
Post by Kay Sievers
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?
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.
Hello Kay,

Can you comment on this please. Is systemd not able to deal with this?

Regards
Mark
Lennart Poettering
2012-04-22 10:54:29 UTC
Permalink
Post by Mark Hounschell
Post by Mark Hounschell
Post by Kay Sievers
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?
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.

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
--
Lennart Poettering - Red Hat, Inc.
Mark Hounschell
2012-04-23 12:33:54 UTC
Permalink
Post by Lennart Poettering
Post by Mark Hounschell
Post by Mark Hounschell
Post by Kay Sievers
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?
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"?
Post by Lennart Poettering
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=***@tty1.service

Wants=***@tty1.service
Wants=***@tty2.service
Wants=syslog.service
Wants=udev.service

Conflicts=***@tty3.service
Conflicts=***@tty4.service
Conflicts=***@tty5.service
Conflicts=***@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
Mark Hounschell
2012-04-26 11:39:47 UTC
Permalink
Post by Mark Hounschell
Post by Lennart Poettering
Post by Mark Hounschell
Post by Mark Hounschell
Post by Kay Sievers
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?
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"?
Post by Lennart Poettering
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
Wants=syslog.service
Wants=udev.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

Lennart Poettering
2012-04-10 21:07:12 UTC
Permalink
Post by Mark Hounschell
Post by Colin Guthrie
Post by Mark Hounschell
I'm not a systemd developer but I am trying to use it in place of
sysvinit to create a dedicated "run-level" for our application. Is this
list an appropriate place to inquire about problems I have?
Yup, ask questions here, but make sure you've read up on the various
articles and documentation and such like on
http://www.freedesktop.org/wiki/Software/systemd first :)
Thanks, I've read a lot but nowhere did I find pointers to do what I
need to do. So I thought I would just try to understand the process
of getting to "single-user" mode. I expected that I would be able
to look at /lib/systemd/system/single.target for a starting point
but it's just a link to /dev/null? I was then lost....
So I just created a test target that I expected/hoped would just
start a single mingetty on tty1. It did do that but I also got
agettys on ttys 2-6. I also got some unwanted Console-Kit and Polkit
stuff running that I also do not want or need. Again, I'm trying to
understand how to create a run-level under which everything running
is controlled by me.
systemd does not require CK, but some legacy software still pulls it
in. On Fedora 17 all major components have been updated not to require
CK anymore, but if you install KDE or some other less modern system it
is still pulled in.

Note that we strongly encourage everybody to use agetty instead of
mingetty. agetty is vastly more powerful, better tested and uses less
runtime memory than mingetty. agetty is part of util-linux and hence
installed anyway, while mingetty is a package of its own. Due to that
you will end up having more work and wasting more disk space and runtime
memory by using mingetty.

However, if you really want to use mingetty, then consider editing
Post by Mark Hounschell
My /etc/systemd/system/test.target file
Description=TEST run-level-4 target
DefaultDependencies=no
DefaultDependencies=no should not be necessary for a normal target.
Post by Mark Hounschell
AllowIsolate=yes
[Install]
Alias=test.target
You already have the file name of "test.target", hence an installed
alias of "test.target" makes little sense.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Mark Hounschell
2012-04-11 11:41:25 UTC
Permalink
Post by Lennart Poettering
Post by Mark Hounschell
Post by Colin Guthrie
Post by Mark Hounschell
I'm not a systemd developer but I am trying to use it in place of
sysvinit to create a dedicated "run-level" for our application. Is this
list an appropriate place to inquire about problems I have?
Yup, ask questions here, but make sure you've read up on the various
articles and documentation and such like on
http://www.freedesktop.org/wiki/Software/systemd first :)
Thanks, I've read a lot but nowhere did I find pointers to do what I
need to do. So I thought I would just try to understand the process
of getting to "single-user" mode. I expected that I would be able
to look at /lib/systemd/system/single.target for a starting point
but it's just a link to /dev/null? I was then lost....
So I just created a test target that I expected/hoped would just
start a single mingetty on tty1. It did do that but I also got
agettys on ttys 2-6. I also got some unwanted Console-Kit and Polkit
stuff running that I also do not want or need. Again, I'm trying to
understand how to create a run-level under which everything running
is controlled by me.
systemd does not require CK, but some legacy software still pulls it
in. On Fedora 17 all major components have been updated not to require
CK anymore, but if you install KDE or some other less modern system it
is still pulled in.
Note that we strongly encourage everybody to use agetty instead of
mingetty. agetty is vastly more powerful, better tested and uses less
runtime memory than mingetty. agetty is part of util-linux and hence
installed anyway, while mingetty is a package of its own. Due to that
you will end up having more work and wasting more disk space and runtime
memory by using mingetty.
However, if you really want to use mingetty, then consider editing
Well, I just assumed, obviously incorrectly the opposite, and mingetty
has been the default in a Suse dist. This is really just an exercise for
me to understand how to do what I've been doing in sysvinit all along.
I'll keep agetty in mind then.
Post by Lennart Poettering
Post by Mark Hounschell
My /etc/systemd/system/test.target file
Description=TEST run-level-4 target
DefaultDependencies=no
DefaultDependencies=no should not be necessary for a normal target.
Post by Mark Hounschell
AllowIsolate=yes
[Install]
Alias=test.target
You already have the file name of "test.target", hence an installed
alias of "test.target" makes little sense.
Thanks for the pointers. I guess I need to read more of the doc.

Regards
Mark
Continue reading on narkive:
Loading...