I run into this bug since some time, but wanted to post it here definitelly. The problem is that openrc seems to skip starting of some services which should be started because they are listed in that runlevel (by rc-show). I will post several files proving that along with the rclog file. In that case, skipped services are: bluetooth, hwclock, keymaps, and possibly more. Affected (and tested) runlevels: boot, default. Reproducible: Always
Created attachment 267127 [details] rc-update show Output from rc-update show
Created attachment 267129 [details] /var/log/rc.log Log output from OpenRC
Created attachment 267131 [details] /etc/rc.conf Configuration file for OpenRC
Created attachment 267133 [details] emerge --info openrc Information about openrc version (latest ~amd64), and my system in general.
Forgot to mention that, that services can be started by hand by /etc/init.d/foo start with no problems at all, so it is not a configuration problem of those services.
does it work fine if you disable parallel ?
I've commented the rc_parallel line to test. Result is not 100% equal but still failing. In this new case, without parallel, now bluetooth starts but neither keymaps neither hwclock started this time. And, despide /etc/init.d/bluetooth reports its status as started, bluedevil from KDE does not work until manually restart it.
do you have /lib64/rc/init.d mounted ? do you have crap on your rootfs screwing things up ? mkdir /mnt/tmp mount --bind / /mnt/tmp ls /mnt/tmp/lib64/rc/init.d/
(In reply to comment #8) > do you have /lib64/rc/init.d mounted ? do you have crap on your rootfs > screwing things up ? > > mkdir /mnt/tmp > mount --bind / /mnt/tmp > ls /mnt/tmp/lib64/rc/init.d/ ls /mnt/tmp/lib64/rc/init.d/ coldplugged daemons depcache depconfig deptree exclusive exitcodes failed hotplugged inactive options scheduled snapshot softscripts started starting stopping tmp wasinactive
I believe I am also experiencing this with hwclock. At boot I get the error "cannot set the system time from the hardware clock" Yet as soon as am at the shell hwclock -s works just fine. Been happening for ~a month now.
Do it appear as "started"? In my case some services are really skipped (and marked as stopped), and others (like bluetooth), are started without really being started (because they don't work until I manually restart). It would be useful (I think) to check /etc/init.d/hwclock status prior to set it by hand, to see if openrc thinks it is started or not (despite errors).
Any news in this front? I can still reproduce it with and without parellel startup
I've retested in a clean system, and I discovered a curious thing: packages failing to be started are the same! (hwclock and keymaps specially): Darkness stormbyte # /etc/init.d/keymaps status * status: stopped Darkness stormbyte # /etc/init.d/hwclock status * status: stopped Darkness stormbyte # rc-update show NetworkManager | default acpid | default avahi-daemon | default avahi-dnsconfd | default bluetooth | default bootmisc | boot consolekit | default cupsd | default dbus | default devfs | sysinit dmesg | sysinit fsck | boot hostname | boot hwclock | boot keymaps | boot default killprocs | shutdown local | default localmount | boot microcode_ctl | boot modules | boot mount-ro | shutdown mtab | boot mysql | default net.lo | boot netmount | default postgresql-9.0 | default procfs | boot root | boot savecache | shutdown swap | boot sysctl | boot syslog-ng | default termencoding | boot udev | sysinit udev-postmount | default urandom | boot vixie-cron | default xdm | default Could it be a bug of handling those two specially?
Some time have passed. I formatted and install from scratch and it is still failing (~amd64). Seems I still need to start some init.d scripts by hand, and some other are started normally. For example keymaps is affected too. I realized that putting them manually via rc-update add XXX default does not work either.
Anyway I can debug openrc to know why some services are listed in the autorun but not started in fact? Mainly the hwclock service is of the important services that are not started :(
The version of OpenRC in this report is 0.8.0 which has not been supported for some time. Can you please test with current stable (0.12.4 as of this writing) and let us know if the issue is still occurring? Thanks, William
I went to systemd, that is why I didn't noticed anything more, but I fed up of systemd, and now I am back in OpenRC. Still can reproduce the bug with this new install with openRC: 0.12.4-r4 Also happens to a friend of mine (realized that because his clock was always wrong and had to update it manually in every reboot because hwclock was not being started correctly). As of the time, I discovered that is seems to affect only to low level init scripts (hwclock, consolefont, bluetooth, and the like), but not to other higher level ones (xdm and the like). I update this bug report status accordingly. P.S. As I said before, I am out of ideas of how to debug this, and know why it is happenning, but I am available to follow instructions if you need me to attach logs, or whatever
Also, over the time I found that it only happens to "special" services, like keymaps, and hwclock. Do they have some special thing, or they are just like the others? If so, why are these always failing? I found a similar bugreport about rc cache and date problems, which can be also the cause of this (despite the proposed workaround didn't worked for me). Bug #411461 Also, why if it is present at boot runlevel they are not executed, but others which are present in same boot runlevel are? More tests I did: 1) remove hwclock from boot runlevel and add it to default runlevel => Not executed automatically 2) copy /etc/init.d/hwclock to /etc/init.d/myhwclock and add myhwclock to default runlevel => not executed automatically. I just don't know what more to do, and this is very important, specially when dualboot with windows is present and I am always having the wrong clock (it is set to local, but since the script is not being executed, I always get 2 hours more), and I want to avoid changing to systemd, which is, atm, the only one workaround I found.
Retested with OpenRC-0.22.2, with same synthoms. Any hints of what may be happening, or a way to get a backtrace of why some services are just not being started?
I finally tracked down this whole issue, maybe I was the culprit after all. The reason causing this behavior is in /etc/rc.conf: rc_sys="uml", which I set, leading probably to confusion as of description of "User mode linux". If this was my fault after all, close this bug as invalid, but I suggest a comment there to reflect better this issue. Thank you
As I said in my last post, it was a missconfiguration issue
