Re: [systemd-devel] Jobs dropped to readily (predm/start dropped as a dep while deleting plymouth-quit/stop)
'Twas brillig, and Colin Guthrie at 09/04/12 01:56 did gyre and gimble: > 'Twas brillig, and Colin Guthrie at 09/04/12 00:29 did gyre and gimble: >> Here we can see why prefdm doesn't get started. It was dropped as a dep >> to break an ordering cycle. However, it's actually part of the cycle >> itself, and thus it likely should be excluded from the dependant jobs >> when they are deleted. >> >> i.e. a job may be a dependency of the job being dropped, but it might >> also exist in it's own right as a dep elsewhere. In such circumstances, >> shouldn't it be allowed to continue? >> >> Or perhaps dependant jobs should not be cleared in the first loop. i.e. >> try continuing without deleting dependant jobs, but keep a list of those >> that would be deleted. If the first loop did not solve the problem, then >> delete the deps. >> >> Or perhaps when deleting a stop job, we should not delete any dependant >> start jobs? Or even somehow process conflicts first before verifying the >> order? To explain some of the rules here are: > > Just as a random though, I tried simply not deleting any dependant jobs > as per the attached patch. > > This resulted in the following results: > > Before: > [4.165800] systemd[1]: Activating default unit: default.target > [4.165825] systemd[1]: Trying to enqueue job > graphical.target/start/replace > [4.166048] systemd[1]: Found ordering cycle on basic.target/start > [4.166048] systemd[1]: Walked on cycle path to sockets.target/start > [4.166048] systemd[1]: Walked on cycle path to syslog.socket/start > [4.166048] systemd[1]: Walked on cycle path to basic.target/start > [4.166165] systemd[1]: Breaking ordering cycle by deleting job > syslog.socket/start > [4.166165] systemd[1]: Found ordering cycle on prefdm.service/start > [4.166165] systemd[1]: Walked on cycle path to > plymouth-quit.service/stop > [4.166165] systemd[1]: Walked on cycle path to rc-local.service/start > [4.166165] systemd[1]: Walked on cycle path to rinetd.service/start > [4.166165] systemd[1]: Walked on cycle path to atieventsd.service/start > [4.166165] systemd[1]: Walked on cycle path to prefdm.service/start > [4.166165] systemd[1]: Breaking ordering cycle by deleting job > plymouth-quit.service/stop > [4.166165] systemd[1]: Deleting job prefdm.service/start as > dependency of job plymouth-quit.service/stop > [4.166165] systemd[1]: Found ordering cycle on prefdm.service/stop > [4.166171] systemd[1]: Walked on cycle path to getty@tty1.service/start > [4.166179] systemd[1]: Walked on cycle path to > plymouth-quit-wait.service/start > [4.166195] systemd[1]: Walked on cycle path to rc-local.service/start > [4.166198] systemd[1]: Walked on cycle path to rinetd.service/start > [4.166201] systemd[1]: Walked on cycle path to atieventsd.service/start > [4.166204] systemd[1]: Walked on cycle path to prefdm.service/stop > [4.166207] systemd[1]: Breaking ordering cycle by deleting job > getty@tty1.service/start > [4.166311] systemd[1]: Installed new job graphical.target/start as 1 > > > After: > [4.396671] systemd[1]: Activating default unit: default.target > [4.396697] systemd[1]: Trying to enqueue job > graphical.target/start/replace > [4.397007] systemd[1]: Found ordering cycle on basic.target/start > [4.397011] systemd[1]: Walked on cycle path to sockets.target/start > [4.397014] systemd[1]: Walked on cycle path to syslog.socket/start > [4.397017] systemd[1]: Walked on cycle path to basic.target/start > [4.397020] systemd[1]: Breaking ordering cycle by deleting job > syslog.socket/start > [4.397026] systemd[1]: Found ordering cycle on prefdm.service/start > [4.397029] systemd[1]: Walked on cycle path to > plymouth-quit.service/stop > [4.397030] systemd[1]: Walked on cycle path to rc-local.service/start > [4.397030] systemd[1]: Walked on cycle path to rinetd.service/start > [4.397030] systemd[1]: Walked on cycle path to atieventsd.service/start > [4.397030] systemd[1]: Walked on cycle path to prefdm.service/start > [4.397030] systemd[1]: Breaking ordering cycle by deleting job > plymouth-quit.service/stop > [4.397030] systemd[1]: Found ordering cycle on prefdm.service/start > [4.397030] systemd[1]: Walked on cycle path to getty@tty1.service/stop > [4.397030] systemd[1]: Walked on cycle path to > plymouth-quit-wait.service/start > [4.397030] systemd[1]: Walked on cycle path to rc-local.service/start > [4.397030] systemd[1]: Walked on cycle path to rinetd.service/start > [4.397030] systemd[1]: Walked on cycle path to atieventsd.service/start > [4.397030] systemd[1]: Walked on cycle path to prefdm.service/start > [4.397030] systemd[1]: Breaking ordering cycle by deleting job > getty@tty1.service/stop > [4.397030] systemd[1]: Looking at job prefdm.service/start > conflicted_by=no > [4.397030] systemd[1]: Looking at job prefdm.service
Re: [systemd-devel] [PATCH] Makefile.am: reduce linked libraries
On Wed, Apr 4, 2012 at 22:02, Kay Sievers wrote: > On Wed, Apr 4, 2012 at 21:59, Gustavo Sverzut Barbieri > wrote: >> On Wed, Apr 4, 2012 at 4:52 PM, Kay Sievers wrote: > >>> It should be possible: selinux, lzma, z should not be needed. I think >>> they just appeared in the systemd tree, and did not in the udev tree. >>> There will be a lot of turnaround in the systemd tree then next weeks >>> and udev will see some changes, so the current state just reflects a: >>> "it builds after the merge" nothing else really. >> >> Oh, then I guessed right :-) >> >> As for the linkage review, yeah it would help. > > Yeah, we will look into that. It's about time to split up util.c in > shared/acl.c, shared/pathname.c and such, and let them not pull in all > the stuff which are not needed. Libattr and libcap are gone now from the tools which do not need them: http://cgit.freedesktop.org/systemd/systemd/commit/?id=d7832d2c6e0ef5f2839a2296c1cc2fc85c7d9632 Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd inquiry
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@tty1.service autovt@tty2.service ... autovt@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? Regards Mark ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd inquiry
'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@tty1.service autovt@tty2.service ... autovt@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@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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd inquiry
On Tue, Apr 10, 2012 at 14:36, Mark Hounschell wrote: > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Makefile.am: reduce linked libraries
On Tue, Apr 10, 2012 at 6:21 AM, Kay Sievers wrote: > Libattr and libcap are gone now from the tools which do not need them: > http://cgit.freedesktop.org/systemd/systemd/commit/?id=d7832d2c6e0ef5f2839a2296c1cc2fc85c7d9632 Great! Thanks for slimming up my initramfs a bit :) Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd inquiry
On 04/10/2012 09:10 AM, Kay Sievers wrote: On Tue, Apr 10, 2012 at 14:36, Mark Hounschell wrote: 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. 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. 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd inquiry
On Tue, Apr 10, 2012 at 16:26, Mark Hounschell wrote: > On 04/10/2012 09:10 AM, Kay Sievers wrote: >> 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. >> 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd inquiry
'Twas brillig, and Colin Guthrie at 10/04/12 13:57 did gyre and gimble: > '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@tty1.service autovt@tty2.service ... autovt@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@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. 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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] ignore ENOENT from can_install in listing unit files
A broken .include link in a unit file will cause 'systemctl
list-unit-files' to simply return 'No such file or directory'. Ignore
this silly error, since we know that the file really does exist.
---
Is there anything that can be done, short of enabling debug level logging, to
make hunting down errors like this a little easier? The bare strerror
messages are pretty useless.
src/install.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/install.c b/src/install.c
index 9256116..30b6911 100644
--- a/src/install.c
+++ b/src/install.c
@@ -1896,7 +1896,7 @@ int unit_file_get_list(
goto found;
r = unit_file_can_install(&paths, root_dir, f->path,
true);
-if (r < 0) {
+if (r < 0 && r != -ENOENT) {
free(f->path);
free(f);
goto finish;
--
1.7.10
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Jobs dropped to readily (predm/start dropped as a dep while deleting plymouth-quit/stop)
On Tue, 10 Apr 2012 09:47:06 +0100 Colin Guthrie wrote: > > 2. When resolving ordering cycles, is it really right to delete the > whole job? That's quite drastic action! While I can see the logic in NOT > doing this, would it be better to simply drop a given ordering > dependency, not the job itself? What I mean is, still carry on with the > job requested but accept that we'll have done it at the wrong time. > > I'm not really sure if it's better to do a job at the wrong time or to > simply not do it at all. I think the latter actually seems more correct > (i.e. no change). Just thought I'd mention it. > I can see two benefits in dropping the job, as it's done now: 1. You get a bug report instead of users accumulating "randomly failing at boot" jobs. It's "something consistently doesn't start" vs "something randomly fails", and I assume not many people read the logs or care where that randomness comes from. 2. If started out of order, lot of daemons may find relevant paths being empty and start to initialize them, causing long-term damage to the system. -- Mike Kazantsev // fraggod.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logind / logwatch
On Tue, 10.04.12 03:06, Reindl Harald (h.rei...@thelounge.net) wrote: Heya, > i have redirected "systemd-logind" messages for /var/log/messages > to /var/log/secure on Fedora 16, but because they contain always > an ID logwatch is flooded with this messages systemd git now has logind log with the AUTH facility, hence this should now happen automatically, as you requested earlier. (will be available in f18) > would it not be nicer to skip this ID to see in logwatch > how often usernames created sessions via crond or whatever > > detail-observation if there looks something wired will > happen with the logfile containing timestamps, the > current behavior makes logwatch a little bit ugly Hmm, I am not entirely sure I understand what you are asking for? Are you suggesting that because the "logwatch" tool does not recognize our messages it cannot reduce duplicates and you'd like us to change logind to always generate exactly the same log message without including the ever-increasing session ID? Hmm, wouldn't it be more appropriate to update logwatch to deal with this kind of output? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logind / logwatch
Am 10.04.2012 22:23, schrieb Lennart Poettering: > On Tue, 10.04.12 03:06, Reindl Harald (h.rei...@thelounge.net) wrote: > > Heya, > >> i have redirected "systemd-logind" messages for /var/log/messages >> to /var/log/secure on Fedora 16, but because they contain always >> an ID logwatch is flooded with this messages > > systemd git now has logind log with the AUTH facility, hence this should > now happen automatically, as you requested earlier. (will be available > in f18) ok, thank you F17 would be nicer but since rsyslog can deal with teh redirection not so important >> would it not be nicer to skip this ID to see in logwatch >> how often usernames created sessions via crond or whatever >> >> detail-observation if there looks something wired will >> happen with the logfile containing timestamps, the >> current behavior makes logwatch a little bit ugly > > Hmm, I am not entirely sure I understand what you are asking for? > > Are you suggesting that because the "logwatch" tool does not recognize > our messages it cannot reduce duplicates and you'd like us to change > logind to always generate exactly the same log message without including > the ever-increasing session ID? exactly > Hmm, wouldn't it be more appropriate to update logwatch to deal with > this kind of output? if i would be able to do so i would but that is out of my scope :-( signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] watchdog: really return the actual watchdog timeout
On Fri, 06.04.12 21:37, Michael Olbrich (m.olbr...@pengutronix.de) wrote: > In the current code setting the return argument is never reached. Ouch! Good catch! Applied! Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd inquiry
On 04/10/2012 10:52 AM, Kay Sievers wrote: On Tue, Apr 10, 2012 at 16:26, Mark Hounschell wrote: On 04/10/2012 09:10 AM, Kay Sievers wrote: 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/3] make the service property StartLimitAction writeable
On Fri, 06.04.12 21:37, Michael Olbrich (m.olbr...@pengutronix.de) wrote: Heya, > I sent this before, but I didn't get any comments. This is the same series > rebased onto the current master. > This patch series make the service property StartLimitAction writeable. The > first two patches are preparation to make it posible. The third patch > actually implements this. > Why this is useful: Consider a service with rather strict watchdog > settings. StartLimitAction=reboot-force and low StartLimitBurst. If the > service for some reason crashes immediately, then the system might reboot > before a user can interfere. > With StartLimitAction writeable a 'supervisor' service can start before > this service and (based on some use-case dependent data) set > StartLimitAction to 'none'. The user can then resolve the issue. Thanks a lot. All three patches merged! Sorry for the delay. Hmm, so, from your original watchdog work, what is still missing in git? You had some code that "multiplexed" the hw watchdog for individual services, but I couldn't wrap my head around it. Was there anything else left? (Or anything still on your wishlist?) The multiplexing I am still not convinced off, btw. With all the code now in place we can soft-reboot the machine when a specific service doesn't react, and hard-reboot the machine when systemd doesn't react. With the multiplexing in place we'd simply forward the service watchdog events to the hw watchdog, but what precisely would we gain from that? I mean, we already can reboot the machine directly anyway if a service doesn't respond, why add the (potentially fragile) indirection to do the same via the hw watchdog timer? Or in other words, why would somebody choose to make use of this hw watchdog indirection rather than just tell systemd "StartLimitAction=reboot-immediate"? Can you explain? What am I missing? (as a side note: i submitted a little tool to util-linux which queries /dev/watchdog for its state and is useful to figure out what watchdog is available and what its capabilities are. I hope this is merged soon. This should be useful for everybody experimenting with hardware watchdogs...) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd inquiry
On Mon, 09.04.12 09:59, Mark Hounschell (ma...@compro.net) wrote: > > On 04/05/2012 05:23 PM, Colin Guthrie wrote: > >'Twas brillig, and Mark Hounschell at 05/04/12 18:26 did gyre and gimble: > >>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 getty@.service and change the agetty path in there. > My /etc/systemd/system/test.target file > > Description=TEST run-level-4 target > Wants=mingetty@tty1.service > DefaultDependencies=no DefaultDependencies=no should not be necessary for a normal target. > 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd fails start up
On Thu, 05.04.12 20:01, Alex Bosworth (bwortha...@gmail.com) wrote: > I upgraded systemd to version 44 on my exherbo system and ever since > Systemd fails at boot time. > > I've upgraded/reinstalled all the packages that install files to > /etc/system/systemd and /lib/systemd and the directory /lib/systemd > doesn't exist anymore. I've also checked for links under /etc/systemd > and everything is in order. > > (udev has been upgraded to 182.) > > When system boots the root file system gets mounted successfully and > systemd is started but freezes with the message "failed to fully start > up daemon: operation not permitted". The only option at this time is > to hard reset my computer. Could you please provide the full output of systemd in kmsg up to this point with systemd.log_level=debug systemd.log_target=kmsg? There might be a hint in there about what might be going on. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: dovecot and systemd
On Thu, 05.04.12 12:26, Michal Hlavinka (mhlav...@redhat.com) wrote: > >This is what we do in CUPS and what I think is a nice approach since it > >basically means that any user configuration is always taken into > >account. > > Unfortunately, this can't be used here. CUPS offers only one > service, so it always know what to expect on any connection. > Dovecot, on the other hand, provides five services (imap, imaps, > pop3, pop3s, managesieve) and when it gets connection on port that > is not configured in it's config files, it can't know what to do > with the connection. > > So if the connection comes to extra port, it won't be served. There > are three possibilities what can happen next: > 1) just log message that configuration does not match, do nothing > 2) log message and close socket that listens on port dovecot won't serve > 3) log message and terminate dovecot > I think the 2nd option is the best one here. I'd vote for the 2nd option as well. > Does systemd provide any API to close those sockets? Hmm, no, but you can simply close all sockets you get passed and don't know what do with. Just go through the open fds, use the ones you recognize and close the ones you don't. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
