Custom rc.d Service Starts Manually but Not at Boot
A FreeBSD 13.2 backup server runs a locally written daemon, /usr/local/sbin/backupd, with an rc script at /usr/local/etc/rc.d/backupd. The script is mode 0555 and starts correctly when the administrator runs service backupd start. After a reboot, however, service backupd status reports that the daemon is not running. /etc/rc.conf contains backupd_enable="YES", and sysrc backupd_enable returns YES. The script sets rcvar="backupd_enable" and uses daemon to start the binary, but its header contains only a comment with the script name and no PROVIDE, REQUIRE, or KEYWORD lines. The daemon writes to /var/log/backupd.log and ignores SIGHUP. That log has grown to 6 GB, and the administrator wants both to fix boot startup and to rotate the log safely.
1. Explain why manual start works but boot startup does not, and describe how to confirm and fix the rc.d ordering.
Read the worked answer
Manual service backupd start bypasses rcorder and runs the script directly, so it works even if the script has no dependency metadata. At boot, FreeBSD uses rcorder to build the list of scripts. A script without a PROVIDE line is not properly registered in that dependency graph and may be skipped or ordered unpredictably. The missing REQUIRE also means it may run before networking or filesystems it needs.
Confirm with rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | grep backupd and service -e | grep backupd. If backupd does not appear, the header is the problem. Add a proper header, for example:
# PROVIDE: backupd
# REQUIRE: NETWORKING filesystems
# KEYWORD: shutdown
Keep rcvar="backupd_enable". Then run service backupd start, service -e, and reboot in a test window to verify. The script must also be executable and owned by root.
2. How should the 6 GB log be rotated given that backupd ignores SIGHUP?
Read the worked answer
newsyslog normally renames the log and can send a signal so the daemon reopens the new file. Since backupd ignores SIGHUP, a plain newsyslog entry that sends HUP will leave the daemon writing to the renamed file and the space will not be released from the live file. The rotation must therefore include a restart of backupd after the rename, or the daemon must be changed to reopen its log on a signal.
A practical FreeBSD approach is a newsyslog entry in /usr/local/etc/newsyslog.conf.d/backupd.conf with size and retention settings, followed by a small cron or rc-driven script that restarts backupd after newsyslog runs. For example, configure rotation for /var/log/backupd.log, owner root:wheel, mode 640, keep 7 copies, rotate at 1000 KB or daily, and do not rely on HUP. Then run newsyslog -v to check the configuration, force one rotation with newsyslog -F, and restart backupd. Verify with fstat that the daemon holds the new file, not the renamed one.
3. What test plan proves both fixes will survive the next reboot?
Read the worked answer
Test the pieces separately, then together. First run rcorder and service -e to confirm backupd is in the boot set. Start it with service backupd start, check service backupd status, and confirm the process is running. Force a log rotation with newsyslog -F, restart backupd if that is the chosen strategy, and use fstat or lsof to verify the process has the current log file open. Check that old rotated files exist and that disk space was released.
Finally, reboot during a maintenance window. After boot, verify service backupd status, the listening port or other functional check, the log file inode, and that newsyslog's next scheduled run will rotate correctly. If the daemon depends on a mounted backup volume, also confirm the REQUIRE line orders it after the relevant filesystem mount.