Synopsis #
Installing a package, enabling its service, and starting it are separate operations. A message asking to set an rc.conf variable usually means that startup is disabled, not that the package is broken. A process that starts and exits immediately needs a different investigation.
The examples use an installed, configured nginx service. Substitute the actual service name and its documented configuration check for another application.
Find the service and its enable variable #
List available scripts and inspect the selected service:
$ service -l
# service nginx rcvar
The rc script name and its enable variable need not match. Use the variable reported by rcvar; do not invent one from the package name. Packaged scripts normally live under /usr/local/etc/rc.d and package configuration under /usr/local/etc.
Choose temporary or persistent startup #
For a temporary test that leaves boot policy unchanged:
# service nginx onestart
# service nginx onestatus
The one prefix bypasses the enable-variable check. It does not bypass configuration validation, permissions, an occupied port, or other application failures. Stop that temporary instance when finished:
# service nginx onestop
For startup now and on future boots:
# sysrc nginx_enable=YES
# service nginx start
# service nginx status
sysrc saves the setting; it does not start the process. Do not rely solely on a command’s exit status: an rc script can print a refusal to start while returning success. Read the message and verify process and application state.
Check configuration and the listener #
For nginx, validate before starting or reloading:
# /usr/local/sbin/nginx -t
Then inspect the actual sockets:
# sockstat -4 -6 -l
Confirm the intended address, port, and owning process. A listener bound only to loopback is unavailable to remote clients. A wildcard listener can expose more interfaces than intended. Use the application’s own request or health check; for a local nginx configured on its default HTTP port:
$ fetch -o /dev/null http://127.0.0.1/
If local requests succeed but remote requests fail, continue with DNS, routing, and firewall diagnosis . Reinstalling the package does not repair an upstream packet path.
Inspect a process that exits #
Read the application’s configured log and package messages:
$ pkg info -D nginx
# tail -n 50 /var/log/messages
Check the configuration error, data-directory ownership, required mounts, dependencies, and port conflict before retrying. service uses a restricted startup environment, so a daemon that works when launched from an interactive shell may still depend on a missing path or environment variable. Put required settings in the application’s documented configuration or rc variables.
After a controlled reboot, repeat the status and request checks. See Make a system setting persistent when the service works now but does not return at boot.