Re: some issues with /usr/sbin/service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 17.02.2013 08:54, schrieb Xin Li: On 2/16/13 10:24 AM, Chris Rees wrote: On 16 February 2013 18:08, Gary Palmer gpal...@freebsd.org wrote: On Sat, Feb 16, 2013 at 05:38:56PM +, Chris Rees wrote: On 16 February 2013 17:05, Paul Mather p...@gromit.dlib.vt.edu wrote: On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: 16.02.2013 01:32, Jeremy Chadwick ??: Follow up -- I read Alfred's most recent mail. Lo and behold, I find this in /var/log/messages (but such did not come to my terminal): Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Cute. Agreed -- this is unacceptable on two levels (as I see it): 1) These messages should be going to stdout or stderr in some way, so honestly logger(8) should be called with the -s flag (IMO). Fully agreed here. It turns out logger -s has no effect, just like how the echo 12 statements in warn() and err() have no effect either (these should be outputting the warnings in question to stderr) -- see rc.subr's source for what I'm referring to. Gary and I have been discussing this off-list and the reason has been found: service(8) has this code in it: checkyesno $rcvar 2/dev/null echo $file This explains why there's no warn() or err() output on the terminal -- it's being redirected to /dev/null prior. I do not know who maintains the rc(8) and rc.subr(8) framework, but they've got their work cut out for them. (Note: the echo statements in warn() and err() could be replaced with logger -s as I said; this would allow the echo 12 to be removed) 2) These messages should not be displayed at all (i.e. lack of an xxx_enable variable should imply xxx_enable=no). I see this message as one more level of supervision. If undefined at /etc/make.conf the value of xxx_enable is no from the system's POV (i.e. the service is not strarted). From the admininstrators's POV the port was installed BUT is not used. It's up to admininstrator whether it's OK or not -- just let him remind. I believe the point you're trying to make is that the warning in question should 'act as a reminder to the administrator that they need to set xxx_enable=yes in rc.conf'. If not: please explain if you could what you mean, because I don't understand. If so: I strongly disagree with this method of approach, as what you've proposed is a borderline straw man argument. Reminding the admin to set xxx_enable is presently done inside most ports' pkg-message. IMO, this should really be done inside bsd.port.mk when USE_RC_SUBR is used, emitting a message during install that says something like: To enable the xxx service, please add the following to /etc/rc.conf: xxx_enable=yes Of course, I don't know if this would work for packages. The current message for missing xxx_enable in rc.conf is this: WARNING: $xxx_enable is not set properly - see rc.conf(5). The message is entirely misleading for this specific situation; it isn't reminding an administrator -- if anything it's confusing them (thread is case in point). If we're going to cater to ignorance, then the message should reflect the situation. Thus IMO, this is what ***should*** happen: Definition in rc.confBehaviour/result --- --- myprog_enable=yes emit no warnings, service should run myprog_enable=no emit no warnings, service should not run myprog_enable=abc123 emit a warning, service should not run no definition emit no warnings, service should not run I think case 4 (no definition) is a case where a warning should be emitted because it is arguably not immediately apparent what will actually happen if no definition is present. In the case of services in the base OS it is well-defined: every service should have an explicit default in /etc/defaults/rc.conf that you can easily consult to know definitively what will happen with that service. (If it doesn't, that is a bug, IMHO.) For ports, the case is not so clear. There is a general trend for the port rc.d script to default its respective xxx_enable explicitly to NO. But it is not a universal rule that no definition = default to NO. The net/avahi-app port, for example, doesn't default to NO if xxx_enable is not set: it defaults to
Re: some issues with /usr/sbin/service
16.02.2013 01:32, Jeremy Chadwick пишет: Follow up -- I read Alfred's most recent mail. Lo and behold, I find this in /var/log/messages (but such did not come to my terminal): Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Cute. Agreed -- this is unacceptable on two levels (as I see it): 1) These messages should be going to stdout or stderr in some way, so honestly logger(8) should be called with the -s flag (IMO). Fully agreed here. 2) These messages should not be displayed at all (i.e. lack of an xxx_enable variable should imply xxx_enable=no). I see this message as one more level of supervision. If undefined at /etc/make.conf the value of xxx_enable is no from the system's POV (i.e. the service is not strarted). From the admininstrators's POV the port was installed BUT is not used. It's up to admininstrator whether it's OK or not -- just let him remind. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: some issues with /usr/sbin/service
On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: 16.02.2013 01:32, Jeremy Chadwick ??: Follow up -- I read Alfred's most recent mail. Lo and behold, I find this in /var/log/messages (but such did not come to my terminal): Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Cute. Agreed -- this is unacceptable on two levels (as I see it): 1) These messages should be going to stdout or stderr in some way, so honestly logger(8) should be called with the -s flag (IMO). Fully agreed here. It turns out logger -s has no effect, just like how the echo 12 statements in warn() and err() have no effect either (these should be outputting the warnings in question to stderr) -- see rc.subr's source for what I'm referring to. Gary and I have been discussing this off-list and the reason has been found: service(8) has this code in it: checkyesno $rcvar 2/dev/null echo $file This explains why there's no warn() or err() output on the terminal -- it's being redirected to /dev/null prior. I do not know who maintains the rc(8) and rc.subr(8) framework, but they've got their work cut out for them. (Note: the echo statements in warn() and err() could be replaced with logger -s as I said; this would allow the echo 12 to be removed) 2) These messages should not be displayed at all (i.e. lack of an xxx_enable variable should imply xxx_enable=no). I see this message as one more level of supervision. If undefined at /etc/make.conf the value of xxx_enable is no from the system's POV (i.e. the service is not strarted). From the admininstrators's POV the port was installed BUT is not used. It's up to admininstrator whether it's OK or not -- just let him remind. I believe the point you're trying to make is that the warning in question should 'act as a reminder to the administrator that they need to set xxx_enable=yes in rc.conf'. If not: please explain if you could what you mean, because I don't understand. If so: I strongly disagree with this method of approach, as what you've proposed is a borderline straw man argument. Reminding the admin to set xxx_enable is presently done inside most ports' pkg-message. IMO, this should really be done inside bsd.port.mk when USE_RC_SUBR is used, emitting a message during install that says something like: To enable the xxx service, please add the following to /etc/rc.conf: xxx_enable=yes Of course, I don't know if this would work for packages. The current message for missing xxx_enable in rc.conf is this: WARNING: $xxx_enable is not set properly - see rc.conf(5). The message is entirely misleading for this specific situation; it isn't reminding an administrator -- if anything it's confusing them (thread is case in point). If we're going to cater to ignorance, then the message should reflect the situation. Thus IMO, this is what ***should*** happen: Definition in rc.confBehaviour/result --- --- myprog_enable=yes emit no warnings, service should run myprog_enable=no emit no warnings, service should not run myprog_enable=abc123 emit a warning, service should not run no definition emit no warnings, service should not run It's too bad FreeBSD doesn't have a real services framework like Solaris's smf/svccfg/svcs/svcadm, which in itself alleviates this entire situation. Services are registered with svccfg during installation; there's no config file, thus no chance of a no xxx_enable definition situation. This software also comes to mind (folks who think systemd is a great solution should read the 2nd link): http://www.skarnet.org/software/s6/index.html http://www.skarnet.org/software/s6/why.html -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: some issues with /usr/sbin/service
16.02.2013 13:21, Jeremy Chadwick пишет: On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: 16.02.2013 01:32, Jeremy Chadwick ??: Follow up -- I read Alfred's most recent mail. Lo and behold, I find this in /var/log/messages (but such did not come to my terminal): Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Cute. Agreed -- this is unacceptable on two levels (as I see it): [...] 2) These messages should not be displayed at all (i.e. lack of an xxx_enable variable should imply xxx_enable=no). I see this message as one more level of supervision. If undefined at /etc/make.conf the value of xxx_enable is no from the system's POV (i.e. the service is not strarted). From the admininstrators's POV the port was installed BUT is not used. It's up to admininstrator whether it's OK or not -- just let him remind. I believe the point you're trying to make is that the warning in question should 'act as a reminder to the administrator that they need to set xxx_enable=yes in rc.conf'. If not: please explain if you could what you mean, because I don't understand. That's it. But I call it one more level of supervision on purpose. There may be many sisadmins at one system and there may be many systems at one sysadmin. We are humans and make mistakes. One more level of supervision won't hurt. If so: I strongly disagree with this method of approach, as what you've proposed is a borderline straw man argument. Got ypour POV. Reminding the admin to set xxx_enable is presently done inside most ports' pkg-message. IMO, this should really be done inside bsd.port.mk when USE_RC_SUBR is used, emitting a message during install that says something like: To enable the xxx service, please add the following to /etc/rc.conf: xxx_enable=yes Of course, I don't know if this would work for packages. The current message for missing xxx_enable in rc.conf is this: WARNING: $xxx_enable is not set properly - see rc.conf(5). The message is entirely misleading for this specific situation; it isn't reminding an administrator -- if anything it's confusing them (thread is case in point). If we're going to cater to ignorance, then the message should reflect the situation. The message is is entirely misleading -- yes, agreed! It should be reworded. ;-) Thus IMO, this is what ***should*** happen: Definition in rc.confBehaviour/result --- --- myprog_enable=yes emit no warnings, service should run myprog_enable=no emit no warnings, service should not run myprog_enable=abc123 emit a warning, service should not run no definition emit no warnings, service should not run As I've said for system it is already that. But warnings are for humans. And I think that case 2) and 4) are entirely different. I'd rather see the current behavour at 4) but with better explanation. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: some issues with /usr/sbin/service
On 16 Feb 2013 09:21, Jeremy Chadwick j...@koitsu.org wrote: I do not know who maintains the rc(8) and rc.subr(8) framework, but they've got their work cut out for them. That's an interesting comment Care to guess at the obvious answer? :) No-one actively maintains the infrastructure, though there are some knowledgeable and generous individuals who will review patches sent to rc@. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: some issues with /usr/sbin/service
On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: 16.02.2013 01:32, Jeremy Chadwick ??: Follow up -- I read Alfred's most recent mail. Lo and behold, I find this in /var/log/messages (but such did not come to my terminal): Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Cute. Agreed -- this is unacceptable on two levels (as I see it): 1) These messages should be going to stdout or stderr in some way, so honestly logger(8) should be called with the -s flag (IMO). Fully agreed here. It turns out logger -s has no effect, just like how the echo 12 statements in warn() and err() have no effect either (these should be outputting the warnings in question to stderr) -- see rc.subr's source for what I'm referring to. Gary and I have been discussing this off-list and the reason has been found: service(8) has this code in it: checkyesno $rcvar 2/dev/null echo $file This explains why there's no warn() or err() output on the terminal -- it's being redirected to /dev/null prior. I do not know who maintains the rc(8) and rc.subr(8) framework, but they've got their work cut out for them. (Note: the echo statements in warn() and err() could be replaced with logger -s as I said; this would allow the echo 12 to be removed) 2) These messages should not be displayed at all (i.e. lack of an xxx_enable variable should imply xxx_enable=no). I see this message as one more level of supervision. If undefined at /etc/make.conf the value of xxx_enable is no from the system's POV (i.e. the service is not strarted). From the admininstrators's POV the port was installed BUT is not used. It's up to admininstrator whether it's OK or not -- just let him remind. I believe the point you're trying to make is that the warning in question should 'act as a reminder to the administrator that they need to set xxx_enable=yes in rc.conf'. If not: please explain if you could what you mean, because I don't understand. If so: I strongly disagree with this method of approach, as what you've proposed is a borderline straw man argument. Reminding the admin to set xxx_enable is presently done inside most ports' pkg-message. IMO, this should really be done inside bsd.port.mk when USE_RC_SUBR is used, emitting a message during install that says something like: To enable the xxx service, please add the following to /etc/rc.conf: xxx_enable=yes Of course, I don't know if this would work for packages. The current message for missing xxx_enable in rc.conf is this: WARNING: $xxx_enable is not set properly - see rc.conf(5). The message is entirely misleading for this specific situation; it isn't reminding an administrator -- if anything it's confusing them (thread is case in point). If we're going to cater to ignorance, then the message should reflect the situation. Thus IMO, this is what ***should*** happen: Definition in rc.confBehaviour/result --- --- myprog_enable=yes emit no warnings, service should run myprog_enable=no emit no warnings, service should not run myprog_enable=abc123 emit a warning, service should not run no definition emit no warnings, service should not run I think case 4 (no definition) is a case where a warning should be emitted because it is arguably not immediately apparent what will actually happen if no definition is present. In the case of services in the base OS it is well-defined: every service should have an explicit default in /etc/defaults/rc.conf that you can easily consult to know definitively what will happen with that service. (If it doesn't, that is a bug, IMHO.) For ports, the case is not so clear. There is a general trend for the port rc.d script to default its respective xxx_enable explicitly to NO. But it is not a universal rule that no definition = default to NO. The net/avahi-app port, for example, doesn't default to NO if xxx_enable is not set: it defaults to whatever the gnome_enable setting is defined to be. For the base OS, I agree with your case 4; for the land of ports, I don't think the answer is so cut and dried. That is why I think the warning is useful: it reminds admins to look at the service in question and make a firm decision of their own as to whether it should explicitly be turned on or off. It
Re: some issues with /usr/sbin/service
On 16 February 2013 17:05, Paul Mather p...@gromit.dlib.vt.edu wrote:
On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote:
On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote:
16.02.2013 01:32, Jeremy Chadwick ??:
Follow up -- I read Alfred's most recent mail. Lo and behold, I find
this in /var/log/messages (but such did not come to my terminal):
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable
is not set properly - see rc.conf(5).
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is
not set properly - see rc.conf(5).
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is
not set properly - see rc.conf(5).
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING:
$htcacheclean_enable is not set properly - see rc.conf(5).
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable
is not set properly - see rc.conf(5).
Cute. Agreed -- this is unacceptable on two levels (as I see it):
1) These messages should be going to stdout or stderr in some way, so
honestly logger(8) should be called with the -s flag (IMO).
Fully agreed here.
It turns out logger -s has no effect, just like how the echo 12
statements in warn() and err() have no effect either (these should be
outputting the warnings in question to stderr) -- see rc.subr's source
for what I'm referring to.
Gary and I have been discussing this off-list and the reason has been
found: service(8) has this code in it:
checkyesno $rcvar 2/dev/null echo $file
This explains why there's no warn() or err() output on the terminal --
it's being redirected to /dev/null prior.
I do not know who maintains the rc(8) and rc.subr(8) framework, but
they've got their work cut out for them.
(Note: the echo statements in warn() and err() could be replaced with
logger -s as I said; this would allow the echo 12 to be removed)
2) These messages should not be displayed at all (i.e. lack of an
xxx_enable variable should imply xxx_enable=no).
I see this message as one more level of supervision.
If undefined at /etc/make.conf the value of xxx_enable is no from the
system's POV (i.e. the service is not strarted). From the
admininstrators's POV the port was installed BUT is not used. It's up
to admininstrator whether it's OK or not -- just let him remind.
I believe the point you're trying to make is that the warning in
question should 'act as a reminder to the administrator that they need
to set xxx_enable=yes in rc.conf'.
If not: please explain if you could what you mean, because I don't
understand.
If so: I strongly disagree with this method of approach, as what you've
proposed is a borderline straw man argument.
Reminding the admin to set xxx_enable is presently done inside most
ports' pkg-message. IMO, this should really be done inside bsd.port.mk
when USE_RC_SUBR is used, emitting a message during install that says
something like:
To enable the xxx service, please add the following to /etc/rc.conf:
xxx_enable=yes
Of course, I don't know if this would work for packages.
The current message for missing xxx_enable in rc.conf is this:
WARNING: $xxx_enable is not set properly - see rc.conf(5).
The message is entirely misleading for this specific situation; it isn't
reminding an administrator -- if anything it's confusing them (thread
is case in point). If we're going to cater to ignorance, then the
message should reflect the situation.
Thus IMO, this is what ***should*** happen:
Definition in rc.confBehaviour/result
--- ---
myprog_enable=yes emit no warnings, service should run
myprog_enable=no emit no warnings, service should not run
myprog_enable=abc123 emit a warning, service should not run
no definition emit no warnings, service should not run
I think case 4 (no definition) is a case where a warning should be
emitted because it is arguably not immediately apparent what will actually
happen if no definition is present. In the case of services in the base OS
it is well-defined: every service should have an explicit default in
/etc/defaults/rc.conf that you can easily consult to know definitively what
will happen with that service. (If it doesn't, that is a bug, IMHO.)
For ports, the case is not so clear. There is a general trend for the port
rc.d script to default its respective xxx_enable explicitly to NO. But it
is not a universal rule that no definition = default to NO. The
net/avahi-app port, for example, doesn't default to NO if xxx_enable is not
set: it defaults to whatever the gnome_enable setting is defined to be.
With few exceptions, it should be considered a rule that ports rc
scripts contain:
: ${xxx_enable=no}
to avoid this. If you see any ports that don't define the _enable
variable at all, they are wrong and need fixing.
Chris
Re: some issues with /usr/sbin/service
On Sat, Feb 16, 2013 at 05:38:56PM +, Chris Rees wrote: On 16 February 2013 17:05, Paul Mather p...@gromit.dlib.vt.edu wrote: On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: 16.02.2013 01:32, Jeremy Chadwick ??: Follow up -- I read Alfred's most recent mail. Lo and behold, I find this in /var/log/messages (but such did not come to my terminal): Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Cute. Agreed -- this is unacceptable on two levels (as I see it): 1) These messages should be going to stdout or stderr in some way, so honestly logger(8) should be called with the -s flag (IMO). Fully agreed here. It turns out logger -s has no effect, just like how the echo 12 statements in warn() and err() have no effect either (these should be outputting the warnings in question to stderr) -- see rc.subr's source for what I'm referring to. Gary and I have been discussing this off-list and the reason has been found: service(8) has this code in it: checkyesno $rcvar 2/dev/null echo $file This explains why there's no warn() or err() output on the terminal -- it's being redirected to /dev/null prior. I do not know who maintains the rc(8) and rc.subr(8) framework, but they've got their work cut out for them. (Note: the echo statements in warn() and err() could be replaced with logger -s as I said; this would allow the echo 12 to be removed) 2) These messages should not be displayed at all (i.e. lack of an xxx_enable variable should imply xxx_enable=no). I see this message as one more level of supervision. If undefined at /etc/make.conf the value of xxx_enable is no from the system's POV (i.e. the service is not strarted). From the admininstrators's POV the port was installed BUT is not used. It's up to admininstrator whether it's OK or not -- just let him remind. I believe the point you're trying to make is that the warning in question should 'act as a reminder to the administrator that they need to set xxx_enable=yes in rc.conf'. If not: please explain if you could what you mean, because I don't understand. If so: I strongly disagree with this method of approach, as what you've proposed is a borderline straw man argument. Reminding the admin to set xxx_enable is presently done inside most ports' pkg-message. IMO, this should really be done inside bsd.port.mk when USE_RC_SUBR is used, emitting a message during install that says something like: To enable the xxx service, please add the following to /etc/rc.conf: xxx_enable=yes Of course, I don't know if this would work for packages. The current message for missing xxx_enable in rc.conf is this: WARNING: $xxx_enable is not set properly - see rc.conf(5). The message is entirely misleading for this specific situation; it isn't reminding an administrator -- if anything it's confusing them (thread is case in point). If we're going to cater to ignorance, then the message should reflect the situation. Thus IMO, this is what ***should*** happen: Definition in rc.confBehaviour/result --- --- myprog_enable=yes emit no warnings, service should run myprog_enable=no emit no warnings, service should not run myprog_enable=abc123 emit a warning, service should not run no definition emit no warnings, service should not run I think case 4 (no definition) is a case where a warning should be emitted because it is arguably not immediately apparent what will actually happen if no definition is present. In the case of services in the base OS it is well-defined: every service should have an explicit default in /etc/defaults/rc.conf that you can easily consult to know definitively what will happen with that service. (If it doesn't, that is a bug, IMHO.) For ports, the case is not so clear. There is a general trend for the port rc.d script to default its respective xxx_enable explicitly to NO. But it is not a universal rule that no definition = default to NO. The net/avahi-app port, for example, doesn't default to NO if xxx_enable is not set: it defaults to whatever the gnome_enable setting is defined to be. With few exceptions, it should be considered a rule that ports rc scripts contain:
RE: some issues with /usr/sbin/service
(sorry for top-post ... dumb client software) Am I missing something in this entire thread or... Why not utilize the oft-neglected /etc/rc.conf.d directory? Example? My own vimage package which installs: /etc/rc.conf.d/vimage /etc/rc.d/vimage The /etc/rc.conf.d file is a segment of what should appear in /etc/defaults/rc.conf.d and is loaded whenever a service is loaded. The /etc/rc.conf.d acts as a set of underrides just like /etc/defaults/rc.conf does for the rest of the rc system. -- Devin From: owner-freebsd-sta...@freebsd.org [owner-freebsd-sta...@freebsd.org] on behalf of Gary Palmer [gpal...@freebsd.org] Sent: Saturday, February 16, 2013 10:08 AM To: Chris Rees Cc: Jeremy Chadwick; FreeBSD; Boris Samorodov Subject: Re: some issues with /usr/sbin/service On Sat, Feb 16, 2013 at 05:38:56PM +, Chris Rees wrote: On 16 February 2013 17:05, Paul Mather p...@gromit.dlib.vt.edu wrote: On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: 16.02.2013 01:32, Jeremy Chadwick ??: Follow up -- I read Alfred's most recent mail. Lo and behold, I find this in /var/log/messages (but such did not come to my terminal): Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Cute. Agreed -- this is unacceptable on two levels (as I see it): 1) These messages should be going to stdout or stderr in some way, so honestly logger(8) should be called with the -s flag (IMO). Fully agreed here. It turns out logger -s has no effect, just like how the echo 12 statements in warn() and err() have no effect either (these should be outputting the warnings in question to stderr) -- see rc.subr's source for what I'm referring to. Gary and I have been discussing this off-list and the reason has been found: service(8) has this code in it: checkyesno $rcvar 2/dev/null echo $file This explains why there's no warn() or err() output on the terminal -- it's being redirected to /dev/null prior. I do not know who maintains the rc(8) and rc.subr(8) framework, but they've got their work cut out for them. (Note: the echo statements in warn() and err() could be replaced with logger -s as I said; this would allow the echo 12 to be removed) 2) These messages should not be displayed at all (i.e. lack of an xxx_enable variable should imply xxx_enable=no). I see this message as one more level of supervision. If undefined at /etc/make.conf the value of xxx_enable is no from the system's POV (i.e. the service is not strarted). From the admininstrators's POV the port was installed BUT is not used. It's up to admininstrator whether it's OK or not -- just let him remind. I believe the point you're trying to make is that the warning in question should 'act as a reminder to the administrator that they need to set xxx_enable=yes in rc.conf'. If not: please explain if you could what you mean, because I don't understand. If so: I strongly disagree with this method of approach, as what you've proposed is a borderline straw man argument. Reminding the admin to set xxx_enable is presently done inside most ports' pkg-message. IMO, this should really be done inside bsd.port.mk when USE_RC_SUBR is used, emitting a message during install that says something like: To enable the xxx service, please add the following to /etc/rc.conf: xxx_enable=yes Of course, I don't know if this would work for packages. The current message for missing xxx_enable in rc.conf is this: WARNING: $xxx_enable is not set properly - see rc.conf(5). The message is entirely misleading for this specific situation; it isn't reminding an administrator -- if anything it's confusing them (thread is case in point). If we're going to cater to ignorance, then the message should reflect the situation. Thus IMO, this is what ***should*** happen: Definition in rc.confBehaviour/result --- --- myprog_enable=yes emit no warnings, service should run myprog_enable=no emit no warnings, service should not run myprog_enable=abc123 emit a warning, service should not run no definition emit no warnings, service should not run I think case 4 (no definition) is a case where a warning should be emitted because
Re: some issues with /usr/sbin/service
On 16 February 2013 18:08, Gary Palmer gpal...@freebsd.org wrote: On Sat, Feb 16, 2013 at 05:38:56PM +, Chris Rees wrote: On 16 February 2013 17:05, Paul Mather p...@gromit.dlib.vt.edu wrote: On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: 16.02.2013 01:32, Jeremy Chadwick ??: Follow up -- I read Alfred's most recent mail. Lo and behold, I find this in /var/log/messages (but such did not come to my terminal): Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Cute. Agreed -- this is unacceptable on two levels (as I see it): 1) These messages should be going to stdout or stderr in some way, so honestly logger(8) should be called with the -s flag (IMO). Fully agreed here. It turns out logger -s has no effect, just like how the echo 12 statements in warn() and err() have no effect either (these should be outputting the warnings in question to stderr) -- see rc.subr's source for what I'm referring to. Gary and I have been discussing this off-list and the reason has been found: service(8) has this code in it: checkyesno $rcvar 2/dev/null echo $file This explains why there's no warn() or err() output on the terminal -- it's being redirected to /dev/null prior. I do not know who maintains the rc(8) and rc.subr(8) framework, but they've got their work cut out for them. (Note: the echo statements in warn() and err() could be replaced with logger -s as I said; this would allow the echo 12 to be removed) 2) These messages should not be displayed at all (i.e. lack of an xxx_enable variable should imply xxx_enable=no). I see this message as one more level of supervision. If undefined at /etc/make.conf the value of xxx_enable is no from the system's POV (i.e. the service is not strarted). From the admininstrators's POV the port was installed BUT is not used. It's up to admininstrator whether it's OK or not -- just let him remind. I believe the point you're trying to make is that the warning in question should 'act as a reminder to the administrator that they need to set xxx_enable=yes in rc.conf'. If not: please explain if you could what you mean, because I don't understand. If so: I strongly disagree with this method of approach, as what you've proposed is a borderline straw man argument. Reminding the admin to set xxx_enable is presently done inside most ports' pkg-message. IMO, this should really be done inside bsd.port.mk when USE_RC_SUBR is used, emitting a message during install that says something like: To enable the xxx service, please add the following to /etc/rc.conf: xxx_enable=yes Of course, I don't know if this would work for packages. The current message for missing xxx_enable in rc.conf is this: WARNING: $xxx_enable is not set properly - see rc.conf(5). The message is entirely misleading for this specific situation; it isn't reminding an administrator -- if anything it's confusing them (thread is case in point). If we're going to cater to ignorance, then the message should reflect the situation. Thus IMO, this is what ***should*** happen: Definition in rc.confBehaviour/result --- --- myprog_enable=yes emit no warnings, service should run myprog_enable=no emit no warnings, service should not run myprog_enable=abc123 emit a warning, service should not run no definition emit no warnings, service should not run I think case 4 (no definition) is a case where a warning should be emitted because it is arguably not immediately apparent what will actually happen if no definition is present. In the case of services in the base OS it is well-defined: every service should have an explicit default in /etc/defaults/rc.conf that you can easily consult to know definitively what will happen with that service. (If it doesn't, that is a bug, IMHO.) For ports, the case is not so clear. There is a general trend for the port rc.d script to default its respective xxx_enable explicitly to NO. But it is not a universal rule that no definition = default to NO. The net/avahi-app port, for example, doesn't default to NO if xxx_enable is not set: it defaults to whatever the gnome_enable setting is defined to be. With few
Re: some issues with /usr/sbin/service
because of the trees, you lost the forest :-)
service -e lists enabled services in the order they would be executed.
==
since most ports (and I would like to say all), use : ${xxx_enable=no}, then
service -e will give false positives since the scripts are not loaded.
adding the -v could be more verbose, but the message should go to tty.
my .02$
danny
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: some issues with /usr/sbin/service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2/16/13 10:24 AM, Chris Rees wrote: On 16 February 2013 18:08, Gary Palmer gpal...@freebsd.org wrote: On Sat, Feb 16, 2013 at 05:38:56PM +, Chris Rees wrote: On 16 February 2013 17:05, Paul Mather p...@gromit.dlib.vt.edu wrote: On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: 16.02.2013 01:32, Jeremy Chadwick ??: Follow up -- I read Alfred's most recent mail. Lo and behold, I find this in /var/log/messages (but such did not come to my terminal): Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Cute. Agreed -- this is unacceptable on two levels (as I see it): 1) These messages should be going to stdout or stderr in some way, so honestly logger(8) should be called with the -s flag (IMO). Fully agreed here. It turns out logger -s has no effect, just like how the echo 12 statements in warn() and err() have no effect either (these should be outputting the warnings in question to stderr) -- see rc.subr's source for what I'm referring to. Gary and I have been discussing this off-list and the reason has been found: service(8) has this code in it: checkyesno $rcvar 2/dev/null echo $file This explains why there's no warn() or err() output on the terminal -- it's being redirected to /dev/null prior. I do not know who maintains the rc(8) and rc.subr(8) framework, but they've got their work cut out for them. (Note: the echo statements in warn() and err() could be replaced with logger -s as I said; this would allow the echo 12 to be removed) 2) These messages should not be displayed at all (i.e. lack of an xxx_enable variable should imply xxx_enable=no). I see this message as one more level of supervision. If undefined at /etc/make.conf the value of xxx_enable is no from the system's POV (i.e. the service is not strarted). From the admininstrators's POV the port was installed BUT is not used. It's up to admininstrator whether it's OK or not -- just let him remind. I believe the point you're trying to make is that the warning in question should 'act as a reminder to the administrator that they need to set xxx_enable=yes in rc.conf'. If not: please explain if you could what you mean, because I don't understand. If so: I strongly disagree with this method of approach, as what you've proposed is a borderline straw man argument. Reminding the admin to set xxx_enable is presently done inside most ports' pkg-message. IMO, this should really be done inside bsd.port.mk when USE_RC_SUBR is used, emitting a message during install that says something like: To enable the xxx service, please add the following to /etc/rc.conf: xxx_enable=yes Of course, I don't know if this would work for packages. The current message for missing xxx_enable in rc.conf is this: WARNING: $xxx_enable is not set properly - see rc.conf(5). The message is entirely misleading for this specific situation; it isn't reminding an administrator -- if anything it's confusing them (thread is case in point). If we're going to cater to ignorance, then the message should reflect the situation. Thus IMO, this is what ***should*** happen: Definition in rc.confBehaviour/result --- --- myprog_enable=yes emit no warnings, service should run myprog_enable=no emit no warnings, service should not run myprog_enable=abc123 emit a warning, service should not run no definition emit no warnings, service should not run I think case 4 (no definition) is a case where a warning should be emitted because it is arguably not immediately apparent what will actually happen if no definition is present. In the case of services in the base OS it is well-defined: every service should have an explicit default in /etc/defaults/rc.conf that you can easily consult to know definitively what will happen with that service. (If it doesn't, that is a bug, IMHO.) For ports, the case is not so clear. There is a general trend for the port rc.d script to default its respective xxx_enable explicitly to NO. But it is not a universal rule that no definition = default to NO. The net/avahi-app port, for example, doesn't default to NO if xxx_enable is not set: it defaults to whatever the gnome_enable setting is defined to be.
some issues with /usr/sbin/service
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
we want to use this script for server administration purposes. After
doing some testing, for now there are following issues left:
1) every execution of service -e casts a bunch of unnecessary
warnings into /var/log/messages:
... /usr/sbin/service: WARNING: $name_enable is not set
properly - see rc.conf(5).
This is caused by calling checkyesno(), provided by /etc/subr. It
could be solved by using a local function, named checkyes or similar.
The following patch prohibits these annoying messages:
- --- service.orig2013-02-10 20:01:14.0 +0100
+++ service 2013-02-15 08:51:30.0 +0100
@@ -28,6 +28,28 @@
. /etc/rc.subr
load_rc_config 'XXX'
+#
+# checkyes var
+# Test $1 variable.
+# Return 0 if it's yes (et al), nonzero otherwise.
+#
+checkyes()
+{
+eval _value=\$${1}
+debug checkyes: $1 is set to $_value.
+case $_value in
+
+# yes, true, on, or 1
+[Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1)
+return 0
+;;
+
+# everything else
+*)
+return 1
+;;
+esac
+}
usage () {
echo ''
@@ -100,7 +122,7 @@
if grep -q ^rcvar $file; then
eval `grep ^name= $file`
eval `grep ^rcvar $file`
- - checkyesno $rcvar 2/dev/null echo $file
+ checkyes $rcvar 2/dev/null echo $file
fi
done
exit 0
2) service -e does not show ALL enabled services, but only those who
are explicitly enabled in /etc/defaults/rc.conf or /etc/rc.conf.
Is that expected behavior?
To catch all enabled services where the name_enabled variable is set
within the service procedure itself, perhaps a call like service
name status could help.
- --
Regards
Alfred Bartsch
Data-Service GmbH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEeDUMACgkQ5QGe2JdVf3hL5QCggTK3JP9A+ZybIX/iCsuqu5Ic
bYQAn2w7Y2klRoEy7ithoxeVcl4xA2be
=QJmh
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: some issues with /usr/sbin/service
On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
we want to use this script for server administration purposes. After
doing some testing, for now there are following issues left:
1) every execution of service -e casts a bunch of unnecessary
warnings into /var/log/messages:
... /usr/sbin/service: WARNING: $name_enable is not set
properly - see rc.conf(5).
This is caused by calling checkyesno(), provided by /etc/subr. It
could be solved by using a local function, named checkyes or similar.
The following patch prohibits these annoying messages:
{snip}
Your patch, in effectively, rewrites checkyesno() to remove the warn()
call in cases where xxx_enable variables are set to values other than
yes/true/on/1 or no/false/off/0.
Here's a better idea:
Fix your /etc/rc.conf xxx_enable variables which contain values that
aren't permitted. That's what the warn() is for -- to tell you to fix
them. :-)
If there are ports (or worse, rc.d scripts) out there which recommend
xxx_enable variables with non-permitted values, then these ports need to
be fixed, not rc.subr(8) nor service(8). Please disclose what those are
so they can be fixed.
However, service -e does not emit warnings on my 2 systems:
root@icarus:~ # service -e
/etc/rc.d/hostid
/etc/rc.d/zvol
/etc/rc.d/ddb
/etc/rc.d/hostid_save
/etc/rc.d/zfs
/etc/rc.d/cleanvar
/etc/rc.d/ip6addrctl
/etc/rc.d/devd
/etc/rc.d/netwait
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/etc/rc.d/named
/etc/rc.d/ntpdate
/etc/rc.d/dmesg
/etc/rc.d/virecover
/etc/rc.d/motd
/etc/rc.d/ntpd
/etc/rc.d/powerd
/usr/local/etc/rc.d/samba
/usr/local/etc/rc.d/postfix
/usr/local/etc/rc.d/mysql-server
/usr/local/etc/rc.d/apache22
/etc/rc.d/sshd
/etc/rc.d/cron
/etc/rc.d/mixer
/etc/rc.d/inetd
/etc/rc.d/gptboot
root@omake:~ # service -e
/etc/rc.d/hostid
/etc/rc.d/ddb
/etc/rc.d/hostid_save
/etc/rc.d/cleanvar
/etc/rc.d/ip6addrctl
/etc/rc.d/devd
/etc/rc.d/pflog
/etc/rc.d/pf
/etc/rc.d/netwait
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/etc/rc.d/named
/etc/rc.d/ntpdate
/etc/rc.d/dmesg
/etc/rc.d/virecover
/etc/rc.d/motd
/etc/rc.d/ntpd
/usr/local/etc/rc.d/sa-spamd
/usr/local/etc/rc.d/postfix
/usr/local/etc/rc.d/dovecot
/usr/local/etc/rc.d/apache22
/etc/rc.d/sshd
/etc/rc.d/cron
/etc/rc.d/mixer
/etc/rc.d/inetd
/etc/rc.d/gptboot
Regardless: the permitted values (see above) should be documented in
rc.conf(5) somewhere; I don't see any values other than yes
documented, but I'm probably overlooking it.
2) service -e does not show ALL enabled services, but only those who
are explicitly enabled in /etc/defaults/rc.conf or /etc/rc.conf.
Is that expected behavior?
It is the expected behaviour as I understand it per the man page. You
should also see rc(8).
As I understand it, an enabled service is not a process that's
running, but something that has a yes/true/on/1 value for its
xxx_enabled variable in rc.conf/related file. That's just how it works.
If you're used to, for example, Solaris svcs then yes things are
different here.
To catch all enabled services where the name_enabled variable is set
within the service procedure itself, perhaps a call like service
name status could help.
There is already service name status. See rc(8) (search for
status) or try it yourself on a running service. Example:
root@icarus:~ # service postfix status
postfix is running as pid 1378.
Can you rephrase or give an example of what you want?
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: some issues with /usr/sbin/service
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jeremy,
thanks for your quick response. If I understand you right, you don't
see any necessity for updating /usr/sbin/service. I'll try to make my
point of view more comprehensible.
Am 15.02.2013 11:57, schrieb Jeremy Chadwick:
On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
we want to use this script for server administration purposes.
After doing some testing, for now there are following issues
left:
1) every execution of service -e casts a bunch of unnecessary
warnings into /var/log/messages: ... /usr/sbin/service: WARNING:
$name_enable is not set properly - see rc.conf(5). This is
caused by calling checkyesno(), provided by /etc/subr. It could
be solved by using a local function, named checkyes or
similar.
The following patch prohibits these annoying messages: {snip}
Your patch, in effectively, rewrites checkyesno() to remove the
warn() call in cases where xxx_enable variables are set to values
other than yes/true/on/1 or no/false/off/0.
Yes, that's exactly my proposition.
Here's a better idea:
Fix your /etc/rc.conf xxx_enable variables which contain values
that aren't permitted. That's what the warn() is for -- to tell
you to fix them. :-)
That's not the point.
To my knowledge all wrong settings of xxx_enable are reliably
discovered during system startup, where all subr procedures are called
with start as an argument from /etc/rc.
At least in my environment(s) there are no such reported warnings from
startup or shutdown.
service -e does some heuristic attempts to redetermine the
original startup setting of the XXX_enable variable without
executing the startup script, and thus fails in all cases where this
variable setting is done exclusively via the startup script itself.
/usr/bin/service can be run at any time, even if the variable settings
of the system startup (/etc/rc) are no longer valid.
If there are ports (or worse, rc.d scripts) out there which
recommend xxx_enable variables with non-permitted values, then
these ports need to be fixed, not rc.subr(8) nor service(8).
Please disclose what those are so they can be fixed.
However, service -e does not emit warnings on my 2 systems:
The responsible warn() function emits messages to stderr and/or
syslog, but stderr is redirected to /dev/null in /usr/sbin/service, so
these messages can only be seen in /var/log/messages or
/var/log/all.log, if syslog is configured as appropriate (user.notice)
and /usr/bin/logger is executable.
root@icarus:~ # service -e /etc/rc.d/hostid /etc/rc.d/zvol
/etc/rc.d/ddb /etc/rc.d/hostid_save /etc/rc.d/zfs
/etc/rc.d/cleanvar /etc/rc.d/ip6addrctl /etc/rc.d/devd
/etc/rc.d/netwait /etc/rc.d/newsyslog /etc/rc.d/syslogd
/etc/rc.d/named /etc/rc.d/ntpdate /etc/rc.d/dmesg
/etc/rc.d/virecover /etc/rc.d/motd /etc/rc.d/ntpd /etc/rc.d/powerd
/usr/local/etc/rc.d/samba /usr/local/etc/rc.d/postfix
/usr/local/etc/rc.d/mysql-server /usr/local/etc/rc.d/apache22
/etc/rc.d/sshd /etc/rc.d/cron /etc/rc.d/mixer /etc/rc.d/inetd
/etc/rc.d/gptboot
root@omake:~ # service -e /etc/rc.d/hostid /etc/rc.d/ddb
/etc/rc.d/hostid_save /etc/rc.d/cleanvar /etc/rc.d/ip6addrctl
/etc/rc.d/devd /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/netwait
/etc/rc.d/newsyslog /etc/rc.d/syslogd /etc/rc.d/named
/etc/rc.d/ntpdate /etc/rc.d/dmesg /etc/rc.d/virecover
/etc/rc.d/motd /etc/rc.d/ntpd /usr/local/etc/rc.d/sa-spamd
/usr/local/etc/rc.d/postfix /usr/local/etc/rc.d/dovecot
/usr/local/etc/rc.d/apache22 /etc/rc.d/sshd /etc/rc.d/cron
/etc/rc.d/mixer /etc/rc.d/inetd /etc/rc.d/gptboot
Regardless: the permitted values (see above) should be documented
in rc.conf(5) somewhere; I don't see any values other than yes
documented, but I'm probably overlooking it.
This may be true for all system startup scripts (/etc/rc.d) but is
definitively not true for local startup scripts (/usr/local/etc/rc.d,
...). Let us suppose you added XXX_enable settings for your daemons
from ports to /etc/rc.conf and did not install any other port
containing startup script(s). In this particular case there is no
warning emitted.
After installing additional ports containing rc.d scripts without
modifying /etc/rc.conf, you are able to restart your system again and
again without such warnings being emitted, in these cases XXX_enable
of these additional ports normally defaults to NO. During execution
of service -e, XXX_enable defaults to and therefore /etc/subr
emits a warning, which is IMHO at least misleading. The proposed patch
solves this issue for me, YMMV.
2) service -e does not show ALL enabled services, but only
those who are explicitly enabled in /etc/defaults/rc.conf or
/etc/rc.conf. Is that expected behavior?
It is the expected behaviour as I understand it per the man page.
You should also see rc(8).
As I understand it, an enabled service is not a process that's
running, but something that has a yes/true/on/1 value for its
Re: some issues with /usr/sbin/service
On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote:
On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
we want to use this script for server administration purposes. After
doing some testing, for now there are following issues left:
1) every execution of service -e casts a bunch of unnecessary
warnings into /var/log/messages:
... /usr/sbin/service: WARNING: $name_enable is not set
properly - see rc.conf(5).
This is caused by calling checkyesno(), provided by /etc/subr. It
could be solved by using a local function, named checkyes or similar.
The following patch prohibits these annoying messages:
{snip}
Your patch, in effectively, rewrites checkyesno() to remove the warn()
call in cases where xxx_enable variables are set to values other than
yes/true/on/1 or no/false/off/0.
Here's a better idea:
Fix your /etc/rc.conf xxx_enable variables which contain values that
aren't permitted. That's what the warn() is for -- to tell you to fix
them. :-)
It also warns if xxx_enable isn't set. I have a number of ports installed
which I don't want to run by default but may run later, or which have
daemons but I don't want the daemon but some other functionality.
rsync and fetchmail are two perfect examples of the latter.
If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning.
Should I really have to go through and explicitly set the xxx_enable flags
to no? Or should the code be smart enough to recognise that the variable
not being present is equivalent to no?
If the requirement is that all installed rc.d scripts have a xxx_enable flag
set to yes or no at all times, then the current ports infrastructure is sadly
lacking as I don't have anything under /usr/local/etc/defaults/ at all (if
that is even a valid location). And I'd prefer ports not try and automagically
frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove
xxx_enable lines as that can go wrong.
Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: some issues with /usr/sbin/service
On Fri, Feb 15, 2013 at 02:32:10PM -0500, Gary Palmer wrote:
On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote:
On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
we want to use this script for server administration purposes. After
doing some testing, for now there are following issues left:
1) every execution of service -e casts a bunch of unnecessary
warnings into /var/log/messages:
... /usr/sbin/service: WARNING: $name_enable is not set
properly - see rc.conf(5).
This is caused by calling checkyesno(), provided by /etc/subr. It
could be solved by using a local function, named checkyes or similar.
The following patch prohibits these annoying messages:
{snip}
Your patch, in effectively, rewrites checkyesno() to remove the warn()
call in cases where xxx_enable variables are set to values other than
yes/true/on/1 or no/false/off/0.
Here's a better idea:
Fix your /etc/rc.conf xxx_enable variables which contain values that
aren't permitted. That's what the warn() is for -- to tell you to fix
them. :-)
It also warns if xxx_enable isn't set. I have a number of ports installed
which I don't want to run by default but may run later, or which have
daemons but I don't want the daemon but some other functionality.
rsync and fetchmail are two perfect examples of the latter.
If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning.
Should I really have to go through and explicitly set the xxx_enable flags
to no? Or should the code be smart enough to recognise that the variable
not being present is equivalent to no?
If the requirement is that all installed rc.d scripts have a xxx_enable flag
set to yes or no at all times, then the current ports infrastructure is sadly
lacking as I don't have anything under /usr/local/etc/defaults/ at all (if
that is even a valid location). And I'd prefer ports not try and
automagically
frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove
xxx_enable lines as that can go wrong.
This is the first I've heard of something called /usr/local/etc/rc.conf.
What is this file? I don't see it mentioned as being read/used by
rc_conf_files (see /etc/defaults/rc.conf), at least not via stock. Are
you redefining rc_conf_files or are you somehow source'ing the file
yourself?
Regardless, I can't confirm that behaviour:
root@icarus:~ # grep mysql_ /etc/rc.conf
# mysql_enable=yes
# mysql_dbdir=/storage/mysql
root@icarus:~ # service -e
/etc/rc.d/hostid
/etc/rc.d/zvol
/etc/rc.d/ddb
/etc/rc.d/hostid_save
/etc/rc.d/zfs
/etc/rc.d/cleanvar
/etc/rc.d/ip6addrctl
/etc/rc.d/devd
/etc/rc.d/netwait
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/etc/rc.d/named
/etc/rc.d/ntpdate
/etc/rc.d/dmesg
/etc/rc.d/virecover
/etc/rc.d/motd
/etc/rc.d/ntpd
/etc/rc.d/powerd
/usr/local/etc/rc.d/samba
/usr/local/etc/rc.d/postfix
/usr/local/etc/rc.d/apache22
/etc/rc.d/sshd
/etc/rc.d/cron
/etc/rc.d/mixer
/etc/rc.d/inetd
/etc/rc.d/gptboot
Same goes for if I removed the commented-out lines (shouldn't matter but
I tested it anyway).
System:
FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r246644: Sun Feb 10
16:55:49 PST 2013
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64
root@icarus:~ # grep '$FreeBSD' /etc/rc /etc/rc.subr
/etc/rc:# $FreeBSD: stable/9/etc/rc 233943 2012-04-06 11:07:44Z ed $
/etc/rc.subr:# $FreeBSD: stable/9/etc/rc.subr 243754 2012-12-01 15:46:27Z crees
$
I fully agree that if this were the case (having to set xxx_enable=no
explicitly) that would be a bug.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: some issues with /usr/sbin/service
On Fri, Feb 15, 2013 at 01:20:20PM -0800, Jeremy Chadwick wrote:
On Fri, Feb 15, 2013 at 02:32:10PM -0500, Gary Palmer wrote:
On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote:
On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
we want to use this script for server administration purposes. After
doing some testing, for now there are following issues left:
1) every execution of service -e casts a bunch of unnecessary
warnings into /var/log/messages:
... /usr/sbin/service: WARNING: $name_enable is not set
properly - see rc.conf(5).
This is caused by calling checkyesno(), provided by /etc/subr. It
could be solved by using a local function, named checkyes or similar.
The following patch prohibits these annoying messages:
{snip}
Your patch, in effectively, rewrites checkyesno() to remove the warn()
call in cases where xxx_enable variables are set to values other than
yes/true/on/1 or no/false/off/0.
Here's a better idea:
Fix your /etc/rc.conf xxx_enable variables which contain values that
aren't permitted. That's what the warn() is for -- to tell you to fix
them. :-)
It also warns if xxx_enable isn't set. I have a number of ports installed
which I don't want to run by default but may run later, or which have
daemons but I don't want the daemon but some other functionality.
rsync and fetchmail are two perfect examples of the latter.
If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning.
Should I really have to go through and explicitly set the xxx_enable flags
to no? Or should the code be smart enough to recognise that the variable
not being present is equivalent to no?
If the requirement is that all installed rc.d scripts have a xxx_enable flag
set to yes or no at all times, then the current ports infrastructure is
sadly
lacking as I don't have anything under /usr/local/etc/defaults/ at all (if
that is even a valid location). And I'd prefer ports not try and
automagically
frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove
xxx_enable lines as that can go wrong.
This is the first I've heard of something called /usr/local/etc/rc.conf.
What is this file? I don't see it mentioned as being read/used by
rc_conf_files (see /etc/defaults/rc.conf), at least not via stock. Are
you redefining rc_conf_files or are you somehow source'ing the file
yourself?
Regardless, I can't confirm that behaviour:
root@icarus:~ # grep mysql_ /etc/rc.conf
# mysql_enable=yes
# mysql_dbdir=/storage/mysql
root@icarus:~ # service -e
/etc/rc.d/hostid
/etc/rc.d/zvol
/etc/rc.d/ddb
/etc/rc.d/hostid_save
/etc/rc.d/zfs
/etc/rc.d/cleanvar
/etc/rc.d/ip6addrctl
/etc/rc.d/devd
/etc/rc.d/netwait
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/etc/rc.d/named
/etc/rc.d/ntpdate
/etc/rc.d/dmesg
/etc/rc.d/virecover
/etc/rc.d/motd
/etc/rc.d/ntpd
/etc/rc.d/powerd
/usr/local/etc/rc.d/samba
/usr/local/etc/rc.d/postfix
/usr/local/etc/rc.d/apache22
/etc/rc.d/sshd
/etc/rc.d/cron
/etc/rc.d/mixer
/etc/rc.d/inetd
/etc/rc.d/gptboot
Same goes for if I removed the commented-out lines (shouldn't matter but
I tested it anyway).
System:
FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r246644: Sun Feb 10
16:55:49 PST 2013
r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64
root@icarus:~ # grep '$FreeBSD' /etc/rc /etc/rc.subr
/etc/rc:# $FreeBSD: stable/9/etc/rc 233943 2012-04-06 11:07:44Z ed $
/etc/rc.subr:# $FreeBSD: stable/9/etc/rc.subr 243754 2012-12-01 15:46:27Z
crees $
I fully agree that if this were the case (having to set xxx_enable=no
explicitly) that would be a bug.
Follow up -- I read Alfred's most recent mail. Lo and behold, I find
this in /var/log/messages (but such did not come to my terminal):
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not
set properly - see rc.conf(5).
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not
set properly - see rc.conf(5).
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not
set properly - see rc.conf(5).
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is
not set properly - see rc.conf(5).
Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is
not set properly - see rc.conf(5).
Cute. Agreed -- this is unacceptable on two levels (as I see it):
1) These messages should be going to stdout or stderr in some way, so
honestly logger(8) should be called with the -s flag (IMO).
2) These messages should not be displayed at all (i.e. lack of an
xxx_enable variable should imply xxx_enable=no).
I'll file a PR for this.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US
Re: some issues with /usr/sbin/service
On Fri, Feb 15, 2013 at 01:32:57PM -0800, Jeremy Chadwick wrote: I'll file a PR for this. http://www.freebsd.org/cgi/query-pr.cgi?pr=176181 -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: some issues with /usr/sbin/service
On Fri, Feb 15, 2013 at 01:20:20PM -0800, Jeremy Chadwick wrote:
On Fri, Feb 15, 2013 at 02:32:10PM -0500, Gary Palmer wrote:
On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote:
On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
we want to use this script for server administration purposes. After
doing some testing, for now there are following issues left:
1) every execution of service -e casts a bunch of unnecessary
warnings into /var/log/messages:
... /usr/sbin/service: WARNING: $name_enable is not set
properly - see rc.conf(5).
This is caused by calling checkyesno(), provided by /etc/subr. It
could be solved by using a local function, named checkyes or similar.
The following patch prohibits these annoying messages:
{snip}
Your patch, in effectively, rewrites checkyesno() to remove the warn()
call in cases where xxx_enable variables are set to values other than
yes/true/on/1 or no/false/off/0.
Here's a better idea:
Fix your /etc/rc.conf xxx_enable variables which contain values that
aren't permitted. That's what the warn() is for -- to tell you to fix
them. :-)
It also warns if xxx_enable isn't set. I have a number of ports installed
which I don't want to run by default but may run later, or which have
daemons but I don't want the daemon but some other functionality.
rsync and fetchmail are two perfect examples of the latter.
If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning.
Should I really have to go through and explicitly set the xxx_enable flags
to no? Or should the code be smart enough to recognise that the variable
not being present is equivalent to no?
If the requirement is that all installed rc.d scripts have a xxx_enable flag
set to yes or no at all times, then the current ports infrastructure is
sadly
lacking as I don't have anything under /usr/local/etc/defaults/ at all (if
that is even a valid location). And I'd prefer ports not try and
automagically
frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove
xxx_enable lines as that can go wrong.
This is the first I've heard of something called /usr/local/etc/rc.conf.
Sorry, my brain was ahead of where my fingers were and got the path
wrong. I of course meant /etc/rc.conf.
Regardless, I can't confirm that behaviour:
As you found, it gets logged rather than output to stdout or stderr.
Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $xfs_enable is not
set properly - see rc.conf(5).
Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $rsyncd_enable is
not set properly - see rc.conf(5).
Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $rrdcached_enable
is not set properly - see rc.conf(5).
(etc)
I've come across something else outputing that error, but it probably
all comes from the same place. Either the rc processor needs to treat
the flag not being set as equal to no, or the ports infrastructure needs
to start installing something to make foo_enable=no appear in the
defaults system somewhere
Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
