# nginx, upgrade to FreeBSD 13.0 and "host not found in OCSP" msg



## rotor (Dec 19, 2021)

I recently upgraded my server to FreeBSD 13.0 from 12.x.  Current nginx version is nginx-1.20.2_1,2 (installed from pkg).

With FreeBSD 12.x (and 11.x  and...) I ran the command `service -R` and all the services stopped and started without any issues.

Starting with FreeBSD 13.0, when I ran that same command, I'd see the following error message for the nginx startup:

```
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"
```

Long story short...

For some reason, since FreeBSD 13.0, `service -R` stops all the services, then it starts up nginx before unbound is started.  Since unbound is not yet started, the `nginx -t` configuration check produces the above warning, as it cannot find a DNS resolver. (in my nginx.conf, I have the following `resolver  127.0.0.1` )

As a work-around, I modified the /usr/local/etc/rc.d/nginx script, adding unbound to the # REQUIRE section:


```
# REQUIRE: LOGIN cleanvar unbound
```

No more warning when I restart all the services.

But now I do have the concern that my change may be overwritten when the nginx pkg is updated.


----------



## rotor (Dec 25, 2021)

rotor said:


> But now I do have the concern that my change may be overwritten when the nginx pkg is updated.



True to my expressed concern, the change was overwritten when an update for the nginx pkg came down the line.

Is it possible to more permanently specify changes to the /usr/local/etc/rc.d/nginx script?

Maybe something in /etc/rc.conf along the lines of 
	
	



```
nginx_require="+=unbound"
```
  That type of configuration change would at least live through pkg updates.

I looked at the rc.conf documentation, but I didn't see anything like that.  Did I overlook something?

thx.


----------



## nitin (Dec 29, 2021)

I would second rotor that I too have noticed such issues, rather randomly though, in some of our nginx instances. Generally a simple restart resolves the issue. Never bothered to dig deeper.


----------



## rotor (Jan 6, 2022)

I had a chance to look into this a little more.  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 this comparison were replaced by {...} to keep things short.




`rcorder /etc/rc.d/* /usr/local/etc/rc.d/*`


```
{...}
/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`


```
{...}
/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`


```
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 `nginx`.

So I guess my question becomes, why doesn't `service -R` follow the restart order that `service -r` and `rcorder` show?


----------



## covacat (Jan 6, 2022)

service -R only does local services (/usr/local/etc/rc.d/*)
because it does rcorder only on local startup the deps are not solved and the order may differ from /etc/rc.d/ + /usr/local/etc/rc.d/

```
[13:58:26] [host!user]~$rcorder /etc/rc.d/*  /usr/local/etc/rc.d/* 2>/dev/null |grep /local/e
/usr/local/etc/rc.d/stunnel
/usr/local/etc/rc.d/bastille
/usr/local/etc/rc.d/rsyncd
/usr/local/etc/rc.d/mysql-server
[13:58:44] [host!user]~$rcorder /usr/local/etc/rc.d/* 2>/dev/null
/usr/local/etc/rc.d/stunnel
/usr/local/etc/rc.d/rsyncd
/usr/local/etc/rc.d/mysql-server
/usr/local/etc/rc.d/bastille
```


----------



## covacat (Jan 6, 2022)

for correct? operation it needs this patch


```
--- /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="$skip -s nojail"
     fi
     [ -n "$local_startup" ] && find_local_scripts_new
-    files=`rcorder ${skip} ${local_rc} 2>/dev/null`
+    files=`rcorder ${skip} /etc/rc.d/* ${local_rc} 2>/dev/null`
 
     for file in `reverse_list ${files}`; do
+            [ "$file" != ${file#/etc/rc.d/} ] && continue
         if grep -q ^rcvar $file; then
             eval `grep ^name= $file`
             eval `grep ^rcvar $file`
@@ -98,6 +99,7 @@
         fi
     done
     for file in $files; do
+        [ "$file" != ${file#/etc/rc.d/} ] && continue
         if grep -q ^rcvar $file; then
             eval `grep ^name= $file`
             eval `grep ^rcvar $file`
```


----------



## rotor (Jan 7, 2022)

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`

```
{...}
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.
{...}
```


Thank-you.

Is there a next-step I should take to, hopefully, see this patch migrate to a more permanent status in the base?


----------

