I have seen this few times before on another machines. This time I came to file a PR for it. I have isc-dhcp41-server-4.1.e_10,2 installed and enabled in rc.conf but service -e doesn't show it: root@xyza ~/# service -e | grep local /usr/local/etc/rc.d/proftpd /usr/local/etc/rc.d/smartd /usr/local/etc/rc.d/rsyncd /usr/local/etc/rc.d/amavis-p0fanalyzer /usr/local/etc/rc.d/mysql-server /usr/local/etc/rc.d/amavisd /usr/local/etc/rc.d/courier-authdaemond /usr/local/etc/rc.d/postfix /usr/local/etc/rc.d/courier-imap-pop3d-ssl /usr/local/etc/rc.d/courier-imap-pop3d /usr/local/etc/rc.d/courier-imap-imapd-ssl /usr/local/etc/rc.d/courier-imap-imapd /usr/local/etc/rc.d/bsdstats /usr/local/etc/rc.d/apache24 The rc file is there root@xyza ~/# /usr/local/etc/rc.d/isc-dhcpd Usage: /usr/local/etc/rc.d/isc-dhcpd [fast|force|one|quiet](start|stop|restart|rcvar|enabled|uninstall|configtest|status|poll) It can be started, I can request status etc. root@xyza ~/# service isc-dhcpd start Starting dhcpd. root@xyza ~/# service isc-dhcpd status dhcpd is running as pid 74802. rc.conf contains these lines ## ISC-DHCPd dhcpd_enable="YES" dhcpd_flags="-q" dhcpd_ifaces="nfe0" dhcpd_chroot_enable="YES" All listed services on this machine root@xyza ~/# service -e /etc/rc.d/hostid /etc/rc.d/hostid_save /etc/rc.d/cleanvar /etc/rc.d/ip6addrctl /etc/rc.d/devd /etc/rc.d/pf /etc/rc.d/newsyslog /etc/rc.d/syslogd /etc/rc.d/ntpdate /etc/rc.d/nfsclient /etc/rc.d/dmesg /etc/rc.d/virecover /etc/rc.d/motd /etc/rc.d/ntpd /usr/local/etc/rc.d/proftpd /etc/rc.d/sshd /usr/local/etc/rc.d/smartd /usr/local/etc/rc.d/rsyncd /usr/local/etc/rc.d/amavis-p0fanalyzer /usr/local/etc/rc.d/mysql-server /usr/local/etc/rc.d/amavisd /usr/local/etc/rc.d/courier-authdaemond /usr/local/etc/rc.d/postfix /etc/rc.d/bsnmpd /usr/local/etc/rc.d/courier-imap-pop3d-ssl /usr/local/etc/rc.d/courier-imap-pop3d /usr/local/etc/rc.d/courier-imap-imapd-ssl /usr/local/etc/rc.d/courier-imap-imapd /usr/local/etc/rc.d/bsdstats /usr/local/etc/rc.d/apache24 /etc/rc.d/cron /etc/rc.d/jail /etc/rc.d/mixer /etc/rc.d/gptboot /etc/rc.d/bgfsck root@xyza ~/# uname -srmi FreeBSD 10.2-RELEASE-p10 amd64 GENERIC I don't know why some services (isc-dhcpd in this case) are not shown. How can I track it down?
I did upgrade from FreeBSD 10.2 to 10.3 and upgraded ISC DHCP from 4.1 to 4.3 but problem remains: service -e doesn't show isc-dhcpd service -l shows isc-dhcpd Can somebody look on to this annoying bug?
Add isc-dhcp maintainer to CC. This is because the isc-dhcp script uses parameter expansion to strip the isc- off of $name. See below from a 'sh -x /usr/sbin/service -e'. Note that 'eval name' fails because $name is still defined as whatever service was before it. ... + echo $'foreman_proxy_enable=\'YES\'' + eval $'foreman_proxy_enable=\'YES\'' + foreman_proxy_enable=YES + checkyesno foreman_proxy_enable + echo /usr/local/etc/rc.d/isc-dhcpd /usr/local/etc/rc.d/isc-dhcpd + grep -q ^rcvar /usr/local/etc/rc.d/isc-dhcpd6 + grep '^name=' /usr/local/etc/rc.d/isc-dhcpd6 + eval 'name=${name##*/isc-}' + name=foreman_proxy ...
Created attachment 186509 [details] service.patch Hi, We ran into the same issue with tomcat 8 and 8.5. The attached patch fixes the issue in service itself by querying the service with `run_rc_script … enabled` to figure out if it's enabled or not. I think the way name is defined in tomcat 8 should not be considered an error as it's from what I understand done to make it easier to have multiple instances of tomcat running. Which is done by linking/copying the original rc script and defining the new variables in rc.conf using the name of the new file instead of the old.
Created attachment 186540 [details] service.patch I realised the original patch had an issue with rcvar being empty. Here is an updated patch which works around this by defining a default dummy rcvar incase it's not set in the rc script. Although hacky, it does seem to work.
(In reply to Marius Halden from comment #4) Argh, seems like I messed up when I tested this first. It har the same behaviour as earlier.
CC jilles@, one of our resident gurus.
Note that this is also a problem for services that are unconditionally enabled, like sysctl. And the patch looks promising. I'll try it out when I have time.