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=95ed3294c632f5606327149f10cef1eb34422862 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 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
