| Summary: | sys-apps/openrc-0.9.8.4: services fail to start at boot because of "stalled" deptree cache | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Wojciech Pyczak <nissarin> |
| Component: | OpenRC | Assignee: | OpenRC Team <openrc> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | StormByte |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Thanks for digging into the issue. I am installing a gentoo right now, I'll try what you say. I'm the reporter of #360359 and in fact it seems a duplicate, but you gave me some important info. Many of the times the clock problems are present, so maybe this is the root cause. Let's let devs to set the status of the bug correctly, but I'm glad it sees some light after some time Well.. unfortunatelly I tested that and still failing, even with important services like hwclock. Proof (time is always wrong until manually init hwclock):
rc-update show
acpid | default
bluetooth | default
bootmisc | boot
bumblebee | default
consolekit | default
cronie | default
cupsd | default
dbus | default
devfs | sysinit
dmesg | sysinit
fsck | boot
hostname | boot
hwclock | boot
keymaps | boot
killprocs | shutdown
kmod-static-nodes | sysinit
local | default
localmount | boot
loopback | boot
microcode_ctl | boot
modules | boot
mount-ro | shutdown
mtab | boot
netmount | default
procfs | boot
root | boot
savecache | shutdown
smartd | default
swap | boot
swapfiles | boot
sysctl | boot
sysfs | sysinit
syslog-ng | default
termencoding | boot
tmpfiles.dev | sysinit
tmpfiles.setup | boot
udev | sysinit
urandom | boot
vgl | default
wicd | default
xdm | default
/etc/init.d/hwclock start
hwclock | * Setting system clock using the hardware clock [Local Time] ... [ ok ]
So it was not started after all, even if it is set in boot runlevel. Seems the same as my bugreport though, and not getting much attention sadly.
|
Newly installed services won't start up at boot for no apparent reason (no error or warning messages at all), those services are simply skipped during boot. After a lot of digging, messing around with strace, deptree cache caught my attention and it seems that was a good guess.. Long story short: if /lib64/rc/init.d/deptree is newer than /etc/init.d it won't be updated and that's perfectly normal, problem is, if during installation system time was off ("in the future") for some reason, timestamp of deptree might be off too and installing of new services (updating timestamp of /etc/init.d) won't trigger deptree cache update. Reproducible: Always Steps to Reproduce: Take any service/package you want, uninstall it first if necessary (make sure to remove script from /etc/init.d) and follow example below ;) nizgard ~ # rc-update -u * Caching service dependencies ... [ ok ] nizgard ~ # grep metalog /lib64/rc/init.d/deptree nizgard ~ # touch -d '20130101' /lib64/rc/init.d/deptree nizgard ~ # emerge metalog nizgard ~ # rc-update add metalog * service metalog added to runlevel default nizgard ~ # grep metalog /lib64/rc/init.d/deptree Reboot and check if metalog started/cache was updated. This can be easily fixes by running rc-update -u, that is if you know what's wrong, perhaps rc/rc-update should compare timestamps of related files with current time at some point to prevent such a thing from happening in the first place. PS: This might be duplicate of #360359... PPS: This is somewhat similar to #338257...