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> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | alexanderyt |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Martin Väth
2015-01-25 06:00:55 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. Does this also fail if you use 'before localmount' in /etc/init.d/myshare, and add it to the boot runlevel? (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. 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). |