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...
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.
