Date: Fri, 15 Feb 2013 18:18:24 +0100 From: Alfred Bartsch <bartsch@dssgmbh.de> To: Jeremy Chadwick <jdc@koitsu.org> Cc: freebsd-stable@FreeBSD.org Subject: Re: some issues with /usr/sbin/service Message-ID: <511E6DE0.4030303@dssgmbh.de> In-Reply-To: <20130215105710.GA6130@icarus.home.lan> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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
> xxx_enabled variable in rc.conf/related file. That's just how it
> works.
I'm fully aware of this concept, AFAIK.
> If you're used to, for example, Solaris "svcs" then yes things are
> different here.
Unfortunately my UNIX experience is mostly limited to *BSD (FreeBSD
since 4.5 or so). :-;
>
>> 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?
>
The main difference between rc and service is that rc calls all
scripts via run_rc_script(), and sources them in a subshell with
$1="start" or "stop". Therefore all settings of "XXX_enable" in the
script itself are being respected, whereas "service -e" is limited to
"eval grep ..."
Ports with "XXX_enable="YES" (or similar) in their rc.d script would
be considered as enabled (and started) by /etc/rc. "service -e" would
not catch any of these. This different behavior is IMHO at least
unexpected, if not buggy.
If every rc.d script would provide a "status" (or similar) function
without changing the service's state, service(8) would be able to
gather a complete list of enabled services, like rc(8), and some
additional info, whether these services are actually running or not.
Please don't hesitate to ask, if my phrasing is not fully intelligible
to you. My English knowledge is definitely far away from native
speaker level.:-)
- --
Regards
Alfred Bartsch
Data-Service GmbH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEebeAACgkQ5QGe2JdVf3hSqACcC6xQi6b3w0heGHQSkopqBynH
I8MAoJJoV3dFTifa4F9PJXnY50LKKhYM
=fAdN
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?511E6DE0.4030303>