|Summary:||sys-apps/openrc sometimes forgets to calculate or miscalculates dependencies|
|Product:||Gentoo Hosted Projects||Reporter:||Martin Väth <martin>|
|Component:||OpenRC||Assignee:||OpenRC Team <openrc>|
|Package list:||Runtime testing required:||---|
Description Martin Väth 2015-01-25 06:00:55 UTC
Unfortunately, I am currently not able to produce the problem described here anymore, but perhaps the description is sufficient for the maintainer of openrc. I have created an init-script /etc/init.d/myshare; it is not important here, what it does (it is related with calling mount --make-shared / in the correct moment). What is important is that it needs to be called before "localmount", and therefore I have added rc_need="myshare" to /etc/conf.d/localmount. What might play a role for this bug is that I have not created a file /etc/conf.d/localmount but "only" a symlink by this name, pointing to /etc/conf.d/localmount.64 which contains this line (because I have several systems with identical /etc/conf.d/* and just different sysmlinks). What might also play a role is that I changed all #!/sbin/runscript into #!/sbin/openrc-run recently. After some of the recent openrc upgrades (probably 0.13.6, 0.13.7, or 0.13.8) or perhaps after the above change - I cannot tell exactly when the problem started - I realized that /etc/init.d/myshare is no longer started, although /etc/init.d/localmount is started. This happened reproducible over the many boots. My conjecture was that something went wrong with the calculation of dependencies. So, for testing, I removed the symlink and rename /etc/conf.d/localmount.64 into /etc/conf.d/localmount (without changing the filestamp of the file). After this change, the next boot was correct. Surprisingly, even after restoring the old setting with the symlink, everything continuous to work. Also after calling /lib64/rc/bin/rc-depend --update still everything continuous to work. So I am not able to reproduce the problem anymore. I remember that once there were issues with missing dependency calculation in openrc when some clock has changed or files had ancient filestamps; however, AFAIK there were never any issues with the clock on this system, and I did not mess with the filestamps (except that the date of symlink itself was of course updated in the moment when I restored it).
Comment 1 Martin Väth 2015-02-08 09:12:48 UTC
After upgrading to sys-apps/openrc-0.13.9 and rebooting, the problem re-occured: /etc/init.d/myshare was not started, although /etc/init.d/localmount is started, and /etc/conf.d/localmount (which is no longer a symlink - this was a red herring) contains the assignment rc_need="myshare" The problem vanished after calling /lib/rc/bin/rc-depend --update so it seems that the installation of the ebuild alone causes a manipulation of the dependency cache without declaring the new cache as "outdated". I conjecture that the issue may be related with the fact that the validity test for the dependency cache appears to use timestamps in a moment when the local time is not yet set.
Comment 2 dwfreed 2015-03-19 19:10:32 UTC
Does this also fail if you use 'before localmount' in /etc/init.d/myshare, and add it to the boot runlevel?
Comment 3 Martin Väth 2015-03-21 14:50:30 UTC
(In reply to dwfreed from comment #2) > Does this also fail if you use 'before localmount' in /etc/init.d/myshare, > and add it to the boot runlevel? I cannot test, since I am lacking a reliable path to reproduce the problem: Although it occured again during the previous openrc upgrades, re-emerging openrc now does not seem to trigger the problem.
Comment 4 Martin Väth 2015-04-01 15:39:33 UTC
Now the problem re-occured out of the blue (without an openrc upgrade). I added "myshare" to the boot runlevel, and it was loaded at the next boot. I removed it again from the boot runlevel, and on the next boot everything worked correctly (i.e. now it is again pulled in by the rc_need=...), that is adding/rebooting/removing/rebooting had the same effect as calling manually /lib/rc/bin/rc-depend --update (which would probably also have fixed it according to my previous experience).