When service -e is run, these warnings are generated: Jan 23 02:10:56 mybox myuser: /usr/sbin/service: WARNING: $growfs_enable is not set properly - see rc.conf(5). Jan 23 02:10:56 mybox myuser: /usr/sbin/service: WARNING: $ is not set properly - see rc.conf(5). Jan 23 02:10:56 mybox myuser: /usr/sbin/service: WARNING: $tcsd_enable is not set properly - see rc.conf(5). Jan 23 02:10:57 mybox myuser: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Jan 23 02:10:57 mybox myuser: /usr/sbin/service: WARNING: $mdnsresponderposix_enable is not set properly - see rc.conf(5). Jan 23 02:10:57 mybox myuser: /usr/sbin/service: WARNING: $mdnsd_enable is not set properly - see rc.conf(5). Jan 23 02:10:57 mybox myuser: /usr/sbin/service: WARNING: $ffserver_enable is not set properly - see rc.conf(5). These is true on all my boxes with slightly different warnings.
(In reply to p5B2E9A8F from comment #0) These are the results of various required _enable settings missing (or not set to YES or NO) from /etc/defaults/rc.conf and /etc/rc.conf{,.local}. Compare PC-BSD bug number 12988 (https://bugs.pcbsd.org/issues/12988). The one that doesn't name a setting is particularly worrisome.
>These are the results of various required _enable settings missing (or not set >to YES or NO) from /etc/defaults/rc.conf and /etc/rc.conf{,.local}. In rc.conf there need to be settings different from default. There is no need for explicit setting "NO" and there should be none. A utility like service should not generate false warnings. This is extremely disturbant because administrators try to hunt down those warnings and start a time consuming research, as these entries occur by random on the first look. Warnings in logfiles should not be misleading and they should not be false warnings. If this is true services does a poor job and this is a bug. services uses function checkyesno of /etc/rc.subr which issues the warning but on different prerequisite. Obviously service needs its own function for its purpose. >The one that doesn't name a setting is particularly worrisome. Well this most probably is caused by the same problem. This is worrisome and points to a buggy implementation of service because it does not reveal the filename of the tested file.
This issue is still present in FreeBSD 13.0-RELEASE, I don't understand why this BR has been marked as "FIXED". We are using "service -e" to auto-discover service in Zabbix, so our /var/log/messages log is fullfilled by those irrevelant warnings. At least an option should exists to service to avoid them.
Created attachment 228280 [details] Proposal patch (add a quiet mode)