Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 411461

Summary: sys-apps/openrc- services fail to start at boot because of "stalled" deptree cache
Product: Gentoo Hosted Projects Reporter: Wojciech Pyczak <nissarin>
Component: OpenRCAssignee: OpenRC Team <openrc>
Status: UNCONFIRMED ---    
Severity: normal CC: StormByte
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Package list:
Runtime testing required: ---

Description Wojciech Pyczak 2012-04-10 12:21:07 UTC
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.

This might be duplicate of #360359...

This is somewhat similar to #338257...
Comment 1 David Carlos Manuelda 2015-04-21 00:19:43 UTC
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
Comment 2 David Carlos Manuelda 2015-04-21 17:00:49 UTC
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                          |                       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.