Since the addition of rc-cgroup.sh openrc output is dirty because it doesn't check permissions and try blindly to execute commands it doesn't have rights to do. Reproducible: Always Steps to Reproduce: /etc/init.d/anyservice status Actual Results: LANG=C /etc/init.d/root status /lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpu/tasks: Permission denied /lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpuset/tasks: Permission denied /lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/devices/tasks: Permission denied /lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/freezer/tasks: Permission denied /lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/openrc/tasks: Permission denied mkdir: cannot create directory '/sys/fs/cgroup/openrc/root': Permission denied /lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpu/tasks: Permission denied /lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpuset/tasks: Permission denied /lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/devices/tasks: Permission denied /lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/freezer/tasks: Permission denied /lib/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/openrc/tasks: Permission denied mkdir: cannot create directory '/sys/fs/cgroup/openrc/root': Permission denied * status: started Expected Results: * status: started/crash... without all the mess being a non authorized user to start or stop a service doesn't mean that user cannot check the status of the service and should get a nice output of its status as the user might then query the admin to change that status (restart/stop/start...) sys-apps/openrc-0.12.4 USE="ncurses netifrc pam unicode -debug -newnet (-prefix) (-selinux) -static-libs -tools
Created attachment 378614 [details, diff] rc-cgroup-wperm.patch I can confirm this, though I also get cpuacct and debug cgroup errors (obviously config-dependent.) cgroup_cleanup() is my code, though my copyright isn't on the file. Rest looks like stuff we discussed, though not all of it, and some of it not so well-written (wouldn't get past review in #bash, if you specify sh advice.) Anyhow attaching trivial patch to fix this specific issue; without write permission this function can never work, so it makes perfect sense to check that pre-condition in the function for robustness. The file needs a cleanup rewrite though. I can do that easily enough, though it's a bit disappointing the sh idioms for robustness I repeatedly outlined didn't make it through. I have a feeling the logic may need review, as outlined in comment; as well as the whole sh codebase needing a cleanup, after reviewing commit history.
I can confirm the mess spat out by `/etc/init.d/root status` as a non-root user, and that the single line added by Steve L (comment #1) fixes the cosmetic problem. I'm running amd64 multilib stable, OpenRC version 0.12.4
Actually this might be a dupe. Does anyone have any comments on the solution in bug#500364?
*** This bug has been marked as a duplicate of bug 500364 ***