Bug #3328
closed
rcenable will not add `_enable` prefix
Added by mneumann over 2 years ago. Updated almost 2 years ago.
0%
Description
When I run
```
rcenable dhcpcd
```
I get the following line added to rc.conf:
dhcpcd="YES"
While I'd expect it to be:
dhcpcd_enable="YES"
Updated by tuxillo about 2 years ago
- Status changed from New to Feedback
According to the manpage (https://man.dragonflybsd.org/?command=rc.conf§ion=ANY)
The following list provides a name and short description for each
variable that can be set in the rc.conf file. To set a variable of bool
type, specify either "YES", "TRUE", "ON", or "1". To unset, specify
"NO", "FALSE", "OFF", or "0". These values are case insensitive. The
_enable postfix in the name of a variable for starting a service can be
omitted (as in NetBSD).
Updated by daftaupe almost 2 years ago
Hmm several comments on that one after a few minutes of research.
A weirder thing is that the behaviour or rcenable is different depending on the program it tries to act on.
For dhcpcd I reproduced, I only get dhcpcd="YES" in my /etc/rc.conf file.
I tried with some other daemon, for example sshd, that gives an error but adds a similar non-prefixed variable.
# rcenable sshd [: =: unexpected operator added/modified: sshd=YES Running /etc/rc.d/sshd start sshd already running? (pid=632). # grep sshd /etc/rc.conf sshd=YES # rcrun enable sshd
I tried with a port I had called xrdp, that one did end up being added to rc.conf as xrpd_enable=YES
I compared the rc.d scripts of these 3 and read some parts of manual pages, and
from rc(8) :
rcvar Display which rc.conf(5) variables are used to control
the startup of the service (if any).
What appears in rc.conf is defined by the rcvar value in the script, xrdp has rcvar=xrdp_enable and appears as such, sshd has rcvar=`set_rcvar`, same for dhcpcd when it's run in master mode (that is without giving the script an interface name)
Our rc manual page differs from FreeBSD one, where ours mentions rcvar=`set_rcvar` in EXAMPLES section, FreeBSD's has no mention of this as you can check in https://www.freebsd.org/cgi/man.cgi?query=rc&sektion=8. Instead in the examples, they write rcvar=foo_enable as in their page : https://docs.freebsd.org/en/articles/rc-scripting/#rcng-hookup
rcrun(8) gives the following concerning the enable command
enable Sets the corresponding _enable variable in rc.conf(5) to
"YES" and runs the start command.
So one might expect to see the _enable suffixed variable in rc.conf, but, having the variable without the _enable suffix is sufficient to let the program start, so I guess maybe that manpage should be modified ?
So maybe we're a bit on a hybrid situation where we have some things originating from FreeBSD and some others from FreeBSD leading to that non-homogen behaviour.
It looks like there's a port called rclint that is supposed to be a linter for rc scripts, but to which flavour does it apply to, is a question I have no answer to (probably FreeBSD though).
Updated by daftaupe almost 2 years ago
- Status changed from Feedback to Closed
Reporting an answer from @liweitianux on IRC
02:29 <@aly> daftaupe: hi. i saw your reply to the bug regarding rcenable. the rc framework was initially developed by netbsd, and then imported to freebsd and then inherited by us.
02:30 <@aly> the netbsd version uses 'foo=YES' to enable one service; don't why freebsd changed that to 'foo_enable=YES'. and for us, both versions are supported.
02:32 <@aly> we might have mixed 'rcvar=`set_rcvar`' and 'rcvar=xxx' in base. but all ports use 'rcvar=xxx_enable', as required by freebsd's policy.
So both are expected to work. Closing as this is not a bug.
Updated by mneumann almost 2 years ago
Hey everybody,
I think the issue I was having with this was that dhcpd would not start up at boot time when just giving "dhcpd=YES", or it would not start up when issuing "service dhcpd restart". It might start up with "/etc/rc.d/dhcpd start". IIRC, one of the three things did not work, that's how I noticed the problem. I cannot test this at the moment, but if someone else wants to research this, that'd be great. I might also be completely wrong and my brain cells are leaky. (I should have mentioned this in the issue in the first place).
I think one problem could be the /etc/rc/defaults/rc.conf that contains a `dhcpd_enable=NO` and this might get confused with a `dhcpd=YES` in some way. IIRC, I got similar issues with other services, where calling the script directly would work, while running it via `service abc start` would not.
Updated by mneumann almost 2 years ago
FYI, there is no dhcpd_enable=NO is /etc/defaults/rc.conf...
Updated by daftaupe almost 2 years ago
Ah I see, you mean there's no dhcpcd=NO in /etc/defaults/rc.conf, so that is incoherent.
because I have
% grep dhcpcd /etc/defaults/rc.conf
# the DHCP client, e.g., "dhcpcd" or "dhclient"
dhcpcd_enable="NO" # Set to YES to run dhcpcd in master mode.
dhcpcd_program="/sbin/dhcpcd"
dhcpcd_flags="-b"
Or are you talking about something else as you mention now dhcpd instead of dhcpcd.
So I guess we should just replace dhcpcd_enable="NO" by dhcpcd="NO" in our /etc/defaults/rc.conf, right ?
EDIT :
doas rcenable dhcpcd
# that gives the following
dhcpcd=YES # rcrun enable dhcpcd
# if I boot there's a dhcpcd running, confirmed by then running :
% doas service dhcpcd restart
Stopping dhcpcd.
Starting dhcpcd.
dhcpcd-9.4.1 starting
DUID 00:01:00:01:2b:4b:29:27:52:54:00:7e:af:b8
forked to background, child pid 902
Updated by mneumann almost 2 years ago
@daftaupe: Thanks for testing this. Can you also test if "/etc/rc.d/dhcpd restart" works properly? If yes, then all works perfectly fine and I was just confused by the man page or I might have tried to enable another service without _enable suffix and that did not work as rcvar is set differently for that service. I think, allowing dhcpd=YES but not e.g. postgresql=YES would be confusing...
No, there is a "dhcpd_enable=NO" in my defaults rc.conf, so please ignore what I was writing. There is no dhcpd_enable in FreeBSD's defaults rc.conf :).
Updated by daftaupe almost 2 years ago
@mneumann, it works to call through /etc/rc.d/dhcpcd.
% doas /etc/rc.d/dhcpcd restart
Stopping dhcpcd.
Starting dhcpcd.
dhcpcd-9.4.1 starting
DUID 00:01:00:01:2b:4b:29:27:52:54:00:7e:af:b8
forked to background, child pid 1318