Date: Thu, 13 Jan 2022 18:29:32 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 256137] service(8) "service -R" restarts local daemons in wrong order. Message-ID: <bug-256137-227-6w8eZFL2C1@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-256137-227@https.bugs.freebsd.org/bugzilla/> References: <bug-256137-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256137 --- Comment #2 from MikeM <mike.543@cd74.com> --- Some of the detail from the thread in the FreeBSD forum I cited... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D I notice that the start order of services is different in service -R than either service -r or rcorder /etc/rc.d/* /usr/local/etc/rc.d/*. Some details... Note that lines containing services that don't matter in th= is comparison were replaced by {...} to keep things short. rcorder /etc/rc.d/* /usr/local/etc/rc.d/* Code: {...} /etc/rc.d/FILESYSTEMS {...} /usr/local/etc/rc.d/unbound /etc/rc.d/local_unbound /etc/rc.d/NETWORKING {...} /usr/local/etc/rc.d/nginx /usr/local/etc/rc.d/php-fpm {...} service -r Code: {...} /etc/rc.d/FILESYSTEMS {...} /usr/local/etc/rc.d/unbound /etc/rc.d/local_unbound /etc/rc.d/NETWORKING {...} /usr/local/etc/rc.d/nginx {...} /usr/local/etc/rc.d/php-fpm {...} service -R Code: Stopping nsd. Stopping openntpd. Stopping php_fpm. Waiting for PIDS: 86331. {...} Stopping unbound. Stopping nginx. Performing sanity check on nginx configuration: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "stg-e1.o.lencr.org" in the certificate "/usr/local/etc/certs/public/www.example.com.crt" nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful Starting nginx. nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "stg-e1.o.lencr.org" in the certificate "/usr/local/etc/certs/public/www.example..com.crt" Obtaining a trust anchor... Starting unbound. {...} Starting php_fpm. {...} Notice that in service -R, and only service -R, unbound is started after ng= inx. So I guess my question becomes, why doesn't service -R follow the restart o= rder that service -r and rcorder show? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------- or correct? operation it needs this patch Code: --- /usr/sbin/service 2021-04-09 09:25:01.000000000 +0300 +++ /tmp/service 2022-01-06 14:16:29.217498000 +0200 @@ -85,9 +85,10 @@ skip=3D"$skip -s nojail" fi [ -n "$local_startup" ] && find_local_scripts_new - files=3D`rcorder ${skip} ${local_rc} 2>/dev/null` + files=3D`rcorder ${skip} /etc/rc.d/* ${local_rc} 2>/dev/null` for file in `reverse_list ${files}`; do + [ "$file" !=3D ${file#/etc/rc.d/} ] && continue if grep -q ^rcvar $file; then eval `grep ^name=3D $file` eval `grep ^rcvar $file` @@ -98,6 +99,7 @@ fi done for file in $files; do + [ "$file" !=3D ${file#/etc/rc.d/} ] && continue if grep -q ^rcvar $file; then eval `grep ^name=3D $file` eval `grep ^rcvar $file` ----------------------------------------- I applied the patch, and it seems to fix the issue I was seeing... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D The patch looks to work quite well for my use case. Here's the output produced (with irrelevant lines shown as {...} to keep it short...) # service -R Code: {...} Stopping nginx. Waiting for PIDS: 4460. {...} Stopping unbound. Waiting for PIDS: 68586. Obtaining a trust anchor... Starting unbound. {...} Performing sanity check on nginx configuration: nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful Starting nginx. {...} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There's some more detail in the cited thread, but the above is the important gist of it. thx. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-256137-227-6w8eZFL2C1>