# Changes in rc in FreeBSD13



## Hei (May 4, 2021)

I've been running a web application based on www/node14 on FreeBSD and I had written an rc script which would start the application automatically. I recently upgraded my server from FreeBSD 12 to FreeBSD 13 and found that my web application no longer started automatically. The system message showed that `ld-elf.so.1: Shared object "libuv.so.1.0.0" not found, required by "node"`.  But I did find libuv.so.1.0.0 in /usr/local/lib and I was able to start my web application by running `service webapp start`. I tried reinstalling all packages but to no avail. I then found a post in the mailing list (sorry I can't find it anymore) which suggested to add `DAEMON` after `REQUIRE` in my rc script. After that, my web application starts normally again.

I spent lots of time on fixing this issue. I also checked the release note to see if there is anything that might cause this issue. But, unfortunately I didn't find anything relevant. If I hadn't accidentally stumbled upon that post in the mailing list, I might have looked into a completely wrong direction and wasted more time. Since this did not happen on FreeBSD 12, I wonder what changes have been made to rc in FreeBSD 13 that might have caused this issue. Or how should I find out about changes other than reading the release note? More importantly, how do you sort out upgrade issues like this more efficiently? I do plan to stay on FreeBSD and stay up-to-date so I want to avoid similar things when I upgrade my server to FreeBSD 14, 15, 16, .... (long live FreeBSD!)


----------



## Alain De Vos (May 6, 2021)

A missing shared object looks like your upgrade of packages is not OK.  And this has nothing to do with rc scripts.


----------



## mer (May 6, 2021)

The error message implies either missing library or ld cache was not set up to find it.  You say it is in /usr/local/lib so I think we rule out "missing library" and have to lean more towards "library not found on library search path".  
Perhaps adding DAEMON is causing your rc script to run a little bit later, so something else could updating the ldd cache. There is an /etc/rc.d/ldconfig script so something must run it at some point.
The fact that starting by hand worked is another data point in favor of a new dependency in the rc script.
If you look at /etc/rc.d/DAEMON it acts as an easy require for NETWORKING and SERVERS, and if you look in /etc/rc.d/SERVERS, there is an explict REQUIRE for ldconfig.  So that is why adding a REQUIRE on DAEMON worked for you.

It also means you could look at a 12.x system and see what calls ldconfig if you wanted.


As your question "how to find out about....":  I'm not sure past reading release notes and keeping an eye on the relevant lists. There is a freebsd-rc mailing list that looks appropriate, maybe the ports and ports-bugs too.


----------



## Alain De Vos (May 6, 2021)

What's the output of

```
pkg version -v | grep updating
```


----------



## Hei (May 6, 2021)

Alain De Vos said:


> A missing shared object looks like your upgrade of packages is not OK.  And this has nothing to do with rc scripts.


I upgraded my packages by


```
pkg bootstrap -f
pkg upgrade -f
```

I also thought I might have upgrade my packages incorrectly. But I was able start the service manually. I tried running `pkg check -Bd` but I didn't get any error. I later reinstalled both www/node14 and devel/libuv but it still didn't work. I have another server which just arrived days ago and I installed FreeBSD 13 on it and run the same web application in a jail. The web application did not start automatically until I added DAEMON too.

Also, `pkg version -v | grep updating` shows nothing.


----------



## Hei (May 6, 2021)

mer said:


> The error message implies either missing library or ld cache was not set up to find it.  You say it is in /usr/local/lib so I think we rule out "missing library" and have to lean more towards "library not found on library search path".
> Perhaps adding DAEMON is causing your rc script to run a little bit later, so something else could updating the ldd cache. There is an /etc/rc.d/ldconfig script so something must run it at some point.
> The fact that starting by hand worked is another data point in favor of a new dependency in the rc script.
> If you look at /etc/rc.d/DAEMON it acts as an easy require for NETWORKING and SERVERS, and if you look in /etc/rc.d/SERVERS, there is an explict REQUIRE for ldconfig.  So that is why adding a REQUIRE on DAEMON worked for you.
> ...


Thanks for your suggestions! I will definitely look at a 12.x system to figure out the differences (if any).


----------



## SirDice (May 6, 2021)

Compare the output of `rcorder /etc/rc.d/* /usr/local/etc/rc.d/*` on both 13 and 12. Then you can see if there's any change in the ordering. Perhaps on 12 your deamon somehow started later than /etc/rc.d/ldconfig but on 13 it tries to start earlier.


----------



## mer (May 6, 2021)

I keep forgetting rcorder;  I've not had a need to check things in a long time.  A quick glance between a 13 and 12 BE here, no significant deltas (quick grep ldconfig /etc/rc.d).  There is likely a good argument "You probably should have had DAEMON in there" even on the 12 system.  But since it worked, you never knew.


----------



## SirDice (May 6, 2021)

mer said:


> There is likely a good argument "You probably should have had DAEMON in there" even on the 12 system. But since it worked, you never knew.


That might be the case.


----------

