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.
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