Created attachment 374476 [details] emerge --info Hello, I have a strange bug, which occurs only on one of my Gentoo OS. sys-apps/openrc-0.12.4 On this system, I run a hardened/linux/amd64/no-multilib profile, with graphical daemons, and when I do `rc-status' in any terminal with my non-root id, I have this: % rc-status Runlevel: graphical default [ stopped ] dbus [ started ] alsasound [ started ] xdm [ started ] bluetooth [ started ] Stacked Runlevel: default netmount [ started ] local [ started ] syslog-ng [ started ] fcron [ started ] sshd [ started ] ntpd [ started ] ntp-client [ started ] mcelog [ started ] lm_sensors [ started ] iptables [ started ] ip6tables [ started ] hddtemp [ started ] pcscd [ started ] nginx [ started ] net.enp7s0 [ started ] Dynamic Runlevel: hotplugged zsh: segmentation fault rc-status When I do with root, it looks like: # rc-status Runlevel: graphical dbus [ started ] xdm [ started ] alsasound [ started ] bluetooth [ started ] Stacked Runlevel: default ip6tables [ started ] iptables [ started ] net.enp7s0 [ started ] netmount [ started ] syslog-ng [ started ] ntp-client [ started ] fcron [ started ] hddtemp [ started ] lm_sensors [ started ] mcelog [ started ] nginx [ started ] ntpd [ started ] pcscd [ started ] sshd [ started ] local [ started ] Dynamic Runlevel: hotplugged Dynamic Runlevel: needed xdm-setup [ started ] Dynamic Runlevel: manual syslog-ng [ started ] sshd [ started ] ip6tables [ started ] iptables [ started ] netmount [ started ] dhcpcd [ started ] ntp-client [ started ] fcron [ started ] hddtemp [ started ] lm_sensors [ started ] mcelog [ started ] net.enp7s0 [ started ] nginx [ started ] ntpd [ started ] pcscd [ started ] local [ started ] Do you spot the differences? In non-root id, I have the line default [ stopped ] in my personal graphical runlevel (with wrong status…), and it segfault when trying to display “Dynamic Runlevel: needed” As I wrote in the title, I have a duplication to the bug 298826 https://bugs.gentoo.org/show_bug.cgi?id=298826 I tried recently to remerge the package openrc, but the segfault is still here, so it's not related to a bad sysmlink. Currently, I don't know how I can give you more informations, but I am ready to help you further. But in general, it's only a minor bug, with rc-status. Best regards, -- Thibaud CANALE
I am not seeing this issue in OpenRc from git. If you are comfortable doing so, can you please test with the live ebuild and re-open the bug if this is still an issue? Thanks, William
Hello, (In reply to William Hubbs from comment #1) > I am not seeing this issue in OpenRc from git. If you are comfortable > doing so, can you please test with the live ebuild and re-open the bug > if this is still an issue? It's been a while I am not anymore on hardened/linux/amd64/no-multilib profile, I am currently with hardened/linux/amd64/x32 profile, so, the behavior has changed. The current installed version (and stable) is sys-apps/openrc-0.12.4, the same version when I reported the bug. The segmentation fault is not anymore present, and the output between root and no-root id is identical, but I still have a lot of services in “Dynamic Runlevel: manual”. I noticed that the order of started daemons is not respected, example: the service named local is launched before others (see in attachment my rc.log). Because I got this bug When you talk about the live ebuild, do you talk about the version **9999, or about the experimental overlay? I will try first the **9999 and keep you to update. Thanks for support.
Created attachment 380672 [details] rc.log when booting with runlevel5, named graphical.
Well, I emerge the version **9999, I updated the config files (dispatch-conf), I did a 'rc-update -u', and now, when I do 'rc-status', as root or as non-root, the program is doing a endless loop on 'Stacked Runlevel: default'... I am afraid to reboot. ;-)
I know about that looping when you run rc-status. That is bug #514972; it does not affect booting. One issue per bug please; the issue in comment #2 is not related. I don't know anything about the experimental overlay you mentioned, so I can't help you there. ;-)
Created attachment 381636 [details] emerge --info Hello, Since I don't have anymore this segmentation fault, because I am not using the same system anymore, as I wrote in comment #2, I think we can close this bug. And as you said, we should not talk about this loop problem in this bug. So, it looks like this bug was related to something with nomultilib system, and the current **9999 version (AKA 0.13git-f66f41) has not this bug. Thanks for support.
The issue no longer exists in git, so I am closing this bug. Thanks for the report. William
