On Tue, 2014-06-24 at 16:13 -0700, Adam Williamson wrote:
On Wed, 2014-06-25 at 00:11 +0100, Peter Robinson wrote:
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect.
I'm seeing it, at least appear, to do something like this. There's a new binary, at least since systemd-208 in F-20 (sorry, shitty hotel wifi makes it too hard to do wider triage) called:
/usr/lib/systemd/system-generators/systemd-sysv-generator
What services exactly are you talking about?
I'm seeing the following style of messages in dmesg. The following is a sample but wc tells me there's 343 entries:
[44437.200793] systemd-sysv-generator[24124]: Could not find init script for radvd.service [44437.200810] systemd-sysv-generator[24124]: Could not find init script for ebtables.service [44437.200814] systemd-sysv-generator[24124]: Could not find init script for oddjobd.service [44437.200818] systemd-sysv-generator[24124]: Could not find init script for spice-vdagentd.service [44437.200822] systemd-sysv-generator[24124]: Could not find init script for livesys-late.service [44437.200826] systemd-sysv-generator[24124]: Could not find init script for tcsd.service [44437.200831] systemd-sysv-generator[24124]: Could not find init script for livesys.service [44437.200837] systemd-sysv-generator[24124]: Could not find init script for radvd.service
I can dig further if necessary in the next few days, I'm travelling at the moment and $dayjob is a bit intense so time is limited in the short term :(
Huh, well that's interesting. I guess I'll look into it.
So, I looked, and found:
http://cgit.freedesktop.org/systemd/systemd/commit/src/sysv-generator?id=95e...
if I'm reading that correctly, I think this is basically the way systemd is now handling legacy sysv initscripts - by generating systemd units for them in a transient directory (/run/systemd/generator.late) on the fly at boot time.
That particular error is from the set_dependencies_from_rcnd function. I'm finding myself too dumb to figure out exactly what the generator is trying to do at that point, but I do notice that on my Rawhide system - which is pretty old, old enough to have been sysv at one point - I have a whole ton of dangling symlinks to old initscripts in /etc/rc*.d/, and at a glance, the "Could not find init script for foo.service" messages in my logs map quite nicely to all those dangling symlinks. I suspect if I cleaned them all up, the messages would go away.
I think the "Could not find init script" errors are probably due to this 'dangling symlink' problem, and the fact that .service files are being generated is intentional - just the way systemd is handling remaining sysv services - and not a bug. That's my reading on the situation anyway. You should find the generated .service files match the remaining sysv services you have in /etc/init.d ; that's the case for me:
[adamw@adam isos]$ ls /etc/init.d/ functions livesys-late network vboxadd vboxadd-x11 livesys netconsole README vboxadd-service
[adamw@adam isos]$ ls /run/systemd/generator.late/ livesys-late.service network-online.target.wants vboxadd-service.service livesys.service network.service vboxadd-x11.service netconsole.service vboxadd.service