openrc-run.sh: spurious `break` inside `case` statement in OpenRC 0.63+

[rapidcow]

In openrc-run.sh there is a break inside a case statement. Previously, this break was enclosed by a for loop. But commit 5a95fe73 from #872 removed that for loop. (This commit is included in release 0.63.)

In POSIX, the behavior of break outside of a loop is unspecified. In practice, break is a no-op¹. Shellcheck also documents this. Bash in non-POSIX mode (presumably?) emits a warning, which is how it caught my attention in the first place when I performed a system upgrade on Artix Linux (0.63 to 0.63.1):

(7/9) Reloading system bus configuration...
 * No permission to apply cgroup settings
/usr/lib/openrc/sh/openrc-run.sh: line 313: break: only meaningful in a `for', `while', or `until' loop
 * Reloading D-BUS messagebus config ... [ ok ]

(The permission error was likely triggered because of chroot.)

If the intent is to retain the original logic, then that intent is certainly not honored by the currently stray break, which is acting like a no-op than breaking out of the current case clause.

P.S. The cgroup refactor in #820 also has similar no-op breaks, though that is a draft and not an immediate problem upstream. :)

Footnotes

1. Tested in all POSIX-compatible shells I could get my hands on: bash 5.3.9(1) with --posix, dash 0.5.13.1, ksh 2020.0.0, busybox 1.36.1 sh. I'm (still) not sure which one OpenRC uses, but I hope that confirms it... ↩

[navi-desu]

I'm (still) not sure which one OpenRC uses

openrc uses /bin/sh by default, what is /bin/sh depends on your distro -- alternative it uses whatever -Dshell= is passed at compile time

anyway, thanks for the issue, #1003 should fix this

[rapidcow]

Oh... that was very quick of you...

I'm still going to post my patch that I was going to follow up with; it's slightly different but does the same trick:

From 7ebab85ab1958f425ab6f31a96672a6107d41ee6 Mon Sep 17 00:00:00 2001
Date: Tue, 14 Apr 2026 13:40:48 -0500
Subject: [PATCH] openrc-run.sh: rewrite `break' in case statement

Prior to commit 5a95fe73 (sh/openrc-run: remove unnecessary loops),
the `break' command served to abort the for loop if cgroup settings
are not writable.  Now that the for loop is replaced with a case
statement, `break' is an undefined operation (practically a no-op
in most Bourne shells I've tested, but undesirable nonetheless).

Rewrite `break' with a boolean guard that skips all subsequent
cgroup operations if cgroup settings are not writable.

Conflicts with #820 (cgroups: refactor cgroups), which (in the
current state) would re-introduce such spurious `break's.
---
 sh/openrc-run.sh.in | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/sh/openrc-run.sh.in b/sh/openrc-run.sh.in
index 858ce3e8..859b109a 100644
--- a/sh/openrc-run.sh.in
+++ b/sh/openrc-run.sh.in
@@ -296,19 +296,25 @@ status|describe) ;;
 	[ -n "${rc_ulimit:-$RC_ULIMIT}" ] && apply_ulimits ${rc_ulimit:-$RC_ULIMIT}
 
 	# Apply cgroups settings if defined
+	_cgroup_ok=1
 	if [ "$(command -v cgroup_add_service)" = "cgroup_add_service" ]; then
 		if grep -qs /sys/fs/cgroup /proc/1/mountinfo
 		then
 			if [ -d /sys/fs/cgroup -a ! -w /sys/fs/cgroup ]; then
 				eerror "No permission to apply cgroup settings"
-				break
+				_cgroup_ok=0
 			fi
 		fi
-		cgroup_add_service
+		if [ $_cgroup_ok -eq 1 ]; then
+			cgroup_add_service
+		fi
 	fi
 
-	[ "$(command -v cgroup_set_limits)" = "cgroup_set_limits" ] && cgroup_set_limits
-	[ "$(command -v cgroup2_set_limits)" = "cgroup2_set_limits" ] && cgroup2_set_limits
+	if [ $_cgroup_ok -eq 1 ]; then
+		[ "$(command -v cgroup_set_limits)" = "cgroup_set_limits" ] && cgroup_set_limits
+		[ "$(command -v cgroup2_set_limits)" = "cgroup2_set_limits" ] && cgroup2_set_limits
+	fi
+	unset _cgroup_ok
 	;;
 esac
 
-- 
2.53.0.dirty

Also, I did notice that the shebang at the top of my openrc-run.sh had been replaced by /bin/bash, which does explain how I got those warnings. So while openrc-run.sh aims to be POSIX-compatible, it is not necessarily the case that a strictly POSIX shell runs it.