9:02 p.m.
Something that absolutely needs to be fixed in future FC versions is
services that "misteriously" re-enable themselves.
I'm sure it happened to everyone, so my story is surely not news.
I install a fresh system, remove unnecessary packages, disable services
that are not used at the moment but will be used after a while. All is
good and the system is doing exactly what's supposed to do.
But when I verify with chkconfig the list of enabled services a few
weeks after that... surprise! Many services somehow managed to re-enable
themselves!
I suspect there are two causes:
1. When updating certain packages, the service will mark itself enabled,
regardless of the current status. That is disgusting. This practice must
stop immediately.
2. I think there are certain weekly or monthly crontabs or something
like that that have a nasty habit of thinking themselves smarter than
the sysadmin and make their own decisions of re-enabling services that
were knowingly disabled by the aforementioned sysadmin. This sneaky,
surreptitious, nasty habit must disappear.
Any script, any piece of software, whatever, should not blindingly re-
enable services. The current status of the service (enabled / disabled)
should be checked and the script/software/whatever should not change it.
This goes for the Fedora Core components proper, the Extras, and all the
other independent repositories as well.
There should be some guidelines or a policy for building RPM packages
that contain system services, or daemons, whatever, with regard to
actions taken during install, update and periodic cron jobs - all things
that might change the enabled/disabled status of a service.
Anyway, I will be very happy to follow said policy, since myself I'm
guilty of building RPM packages that do stupid things with chkconfig. I
hereby repent and publicly admit my sinful ways, and I ask everyone to
work together and come up with a clear, better way of dealing with this
class of problems.
Otherwise... you know, software that thinks itself smarter than its
users - that's so Microsoft.
--
Florin Andrei
http://florin.myip.org/
9:08 p.m.
Florin Andrei (florin(a)andrei.myip.org) said:
Something that absolutely needs to be fixed in future FC versions is
services that "misteriously" re-enable themselves.
I'm sure it happened to everyone, so my story is surely not news.
I install a fresh system, remove unnecessary packages, disable services
that are not used at the moment but will be used after a while. All is
good and the system is doing exactly what's supposed to do.
But when I verify with chkconfig the list of enabled services a few
weeks after that... surprise! Many services somehow managed to re-enable
themselves!
Did you run:
chkconfig --del <service> (wrong)
or
chkconfig --level <levels> <service> (right)
?
What services in particular?
Bill
9:16 p.m.
On Mon, Jun 13, 2005 at 10:08:19PM -0400, Bill Nottingham wrote:
Did you run:
chkconfig --del <service> (wrong)
or
chkconfig --level <levels> <service> (right)
?
chkconfig <service> off
is also right, right?
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 81 degrees Fahrenheit.
9:45 p.m.
Matthew Miller (mattdm(a)mattdm.org) said:
On Mon, Jun 13, 2005 at 10:08:19PM -0400, Bill Nottingham wrote:
> Did you run:
> chkconfig --del <service> (wrong)
> or
> chkconfig --level <levels> <service> (right)
> ?
chkconfig <service> off
is also right, right?
Yeah, in fact in the example above, there needs to be an off after
<levels> <service>.
Bill
9:20 p.m.
On Mon, Jun 13, 2005 at 10:08:19PM -0400, Bill Nottingham wrote:
Did you run:
chkconfig --del <service> (wrong)
or
chkconfig --level <levels> <service> (right)
?
chkconfig <service> off
will also work. It *is* somewhat confusing, though. It's a mistake I
made when first using chkconfig; then I saw the problem mentioned, and
bothered to actually read the man page more closely. ;)
John Thacker
9:30 p.m.
On Mon, Jun 13, 2005 at 10:20:24PM -0400, John Thacker wrote:
> Did you run:
> chkconfig --del <service> (wrong)
> or
> chkconfig --level <levels> <service> (right)
> ?
chkconfig <service> off
will also work. It *is* somewhat confusing, though. It's a mistake I
made when first using chkconfig; then I saw the problem mentioned, and
bothered to actually read the man page more closely. ;)
I think it's 'cause "--del" and other options are called out in bold as
bullet points in the man page but on/off is just mentioned in the text.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 81 degrees Fahrenheit.
9:53 p.m.
On Mon, 2005-06-13 at 22:20 -0400, John Thacker wrote:
On Mon, Jun 13, 2005 at 10:08:19PM -0400, Bill Nottingham wrote:
> Did you run:
> chkconfig --del <service> (wrong)
> or
> chkconfig --level <levels> <service> (right)
> ?
chkconfig <service> off
will also work. It *is* somewhat confusing, though. It's a mistake I
made when first using chkconfig; then I saw the problem mentioned, and
bothered to actually read the man page more closely. ;)
I think that is actually the problem.
Why "--del" should be different from "off"? In either case, the
package
should not change the state of the service, period. It's not like
something goes off every once in a blue moon and changes things around -
if there's a change, most likely someone made a decision and did it for
a reason. The software should respect that decision.
Almost always, it's preferable to disable services with "--del",
therefore keeping the list shorter and easier to read for the overworked
sysadmin. It's kind of hard to scan tons of chkconfig lists on many
systems, trying to figure out which ones are on and which are off; those
lists are not easy to read at a glance.
Yes, I know the service is there, yes, I know I can re-enable it later
on, I just want it out of the way for the moment. Packages should not
ignore my decision.
Any way I look at it, I fail to see the reason why "--del" should imply
some kind of weaker decision that "off". If anything, it should be a
stronger statement.
--
Florin Andrei
http://florin.myip.org/
10:09 p.m.
New subject: bad practice: not reading the manpage
Florin Andrei (florin(a)andrei.myip.org) said:
Why "--del" should be different from "off"?
Why are 'rpm -i' and 'rpm -U' different?
Why are 'ln -s' and 'ln' different?
Because they're different things.
'off' - configure the service to not start
'del' - remove all state for the service entirely
Almost always, it's preferable to disable services with
"--del",
therefore keeping the list shorter and easier to read for the overworked
sysadmin. It's kind of hard to scan tons of chkconfig lists on many
systems, trying to figure out which ones are on and which are off; those
lists are not easy to read at a glance.
So, misuse of the command to make --list easier to read is worth
changing the behavior that's existed since the command was introduced?
Bill
10:32 p.m.
New subject: bad practice: not reading the manpage
On Mon, 2005-06-13 at 23:09 -0400, Bill Nottingham wrote:
Florin Andrei (florin(a)andrei.myip.org) said:
> Why "--del" should be different from "off"?
Because they're different things.
'off' - configure the service to not start
'del' - remove all state for the service entirely
But that's a state in itself, functionally equivalent to "off on all
runlevels". It's unique only in the way that it is not preserved by "rpm
-U"
So, misuse of the command to make --list easier to read is worth
changing the behavior that's existed since the command was introduced?
Making --list easier to read is actually very valuable. If you have a
lot of things to take care of, you don't want to spend "brain cycles"
needlessly; plus, which services are on or off is a pretty important
issue, you don't want to make mistakes there.
I've seen this type of problem many times, when sysadmins and software
engineers are looking at the same issue. It's frustrating sometimes to
make engineers understand the issue from a real world perspective;
what's nice, clean and logical in the lab might be a huge drag in the
real world.
I understand, "--del" takes the service to a state that's not preserved
by rpm. Fine. But who did --del? Most likely the sysadmin. Why should
the software disregard a human decision? The system did not end up in
that state at random, but by human intervention. The software should not
overrule it.
Why should --del be different, other than "this is the way our
forefathers did it"?
This is the core of the problem and I don't think I received a good
answer yet.
Tradition is fine and all that, but it should change when it's hampering
the usability. Maybe I spent too much time lately with the Gnome HIG and
stuff like that (not strictly related, I know, but you get the idea),
but I think it's the computer semantics that should bend over backwards
to adapt to human semantics, not the other way around.
--
Florin Andrei
http://florin.myip.org/
10:39 p.m.
New subject: bad practice: not reading the manpage
Florin Andrei (florin(a)andrei.myip.org) said:
> Because they're different things.
>
> 'off' - configure the service to not start
> 'del' - remove all state for the service entirely
But that's a state in itself, functionally equivalent to "off on all
runlevels". It's unique only in the way that it is not preserved by "rpm
-U"
No, it's a state equivalent to 'no state at all'.
This is the core of the problem and I don't think I received a
good
answer yet.
Because you don't randomly change established, documented, and
expected behavior on a whim.
Tradition is fine and all that, but it should change when it's
hampering
the usability. Maybe I spent too much time lately with the Gnome HIG and
stuff like that (not strictly related, I know, but you get the idea),
but I think it's the computer semantics that should bend over backwards
to adapt to human semantics, not the other way around.
You want to help usability? Help work on something better.
http://fedoraproject.org/wiki/FCNewInit
Bill
11:05 p.m.
New subject: bad practice: not reading the manpage
On Mon, Jun 13, 2005 at 08:32:23PM -0700, Florin Andrei wrote:
> 'off' - configure the service to not start
> 'del' - remove all state for the service entirely
But that's a state in itself, functionally equivalent to "off on all
runlevels". It's unique only in the way that it is not preserved by "rpm
-U"
How *could* it be??? That's the _exact_ difference between using "--del"
and
"off".
Making --list easier to read is actually very valuable. If you have
a
lot of things to take care of, you don't want to spend "brain cycles"
needlessly; plus, which services are on or off is a pretty important
issue, you don't want to make mistakes there.
This is a different issue than whether state information should be left on
the system by a command named "--del". There would be several ways to make
the output of this command more readable without mucking with functionality.
(Like, dealing with that nasty xinitd kludge.)
I understand, "--del" takes the service to a state
that's not preserved
by rpm. Fine. But who did --del? Most likely the sysadmin. Why should
the software disregard a human decision? The system did not end up in
that state at random, but by human intervention. The software should not
overrule it.
The sysadmin shouldn't do that, really, without *expecting* it to get reset
to the default at some point -- or, at least, going "oh, duh" when it does.
Why should --del be different, other than "this is the way our
forefathers did it"?
Um, because *removing state information is what --del does*!
There are two possible alteratives: 1) make *no* services (including syslog,
crond, keytable, iptables, etc) start by default or 2) have very
inconsistant and basically unpredictable behavior between upgrading and
installing a package.
Personally, I think it's *much* better to leave things working as they are
-- and to teach people to use the easier and shorter off/on commands.
This is the core of the problem and I don't think I received a
good
answer yet.
You have now. :)
Tradition is fine and all that, but it should change when it's
hampering
the usability. Maybe I spent too much time lately with the Gnome HIG and
stuff like that (not strictly related, I know, but you get the idea),
but I think it's the computer semantics that should bend over backwards
to adapt to human semantics, not the other way around.
Are you seriously suggesting that "--del" is more human-friendly than
"off"?
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 81 degrees Fahrenheit.
3:19 a.m.
New subject: bad practice: not reading the manpage
On Tue, Jun 14, 2005 at 12:05:37AM -0400, Matthew Miller wrote:
On Mon, Jun 13, 2005 at 08:32:23PM -0700, Florin Andrei wrote:
> > 'off' - configure the service to not start
> > 'del' - remove all state for the service entirely
> But that's a state in itself, functionally equivalent to "off on all
> runlevels". It's unique only in the way that it is not preserved by
"rpm
> -U"
How *could* it be??? That's the _exact_ difference between using "--del"
and
"off".
Precisely. What the original poster is asking for seems to be
equivalent to asking for state to be preserved in this case:
chkconfig foo off
rpm -e foo
rpm -i foo-1-1.rpm
However, it does sound to me like there should at least be a warning
in the man page that packaged services should be disabled using
'off'...
...although, having actually read it, there already *is* such a
warning:
--del name
The service is removed from chkconfig management, and
any symbolic links in /etc/rc[0-6].d which pertain to
it are removed.
Note that future package installs for this service may
run chkconfig --add, which will re-add such links. To
disable a service, run chkconfig name off.
Perhaps chkconfig should check whether it's running from a tty and ask
for confirmation. :-)
Tim.
*/
4:40 a.m.
New subject: bad practice: not reading the manpage
On Tue, 2005-06-14 at 09:19 +0100, Tim Waugh wrote:
...although, having actually read it, there already *is* such a
warning:
--del name
The service is removed from chkconfig management, and
any symbolic links in /etc/rc[0-6].d which pertain to
it are removed.
Note that future package installs for this service may
run chkconfig --add, which will re-add such links. To
disable a service, run chkconfig name off.
I think that was added to the man page when I had this exact same issue
and the man page wasn't clear.
imho another solution is to simply have upgrade to absolutely nothing
with chkconfig, other than checking to see if the service needs to be
restarted. That way if --del was used, it won't --add it again.
Install use --add
upgrade do nothing (other than restart service if on)
12:14 p.m.
New subject: bad practice: not reading the manpage
On Tue, 2005-06-14 at 09:19 +0100, Tim Waugh wrote:
Precisely. What the original poster is asking for seems to be
equivalent to asking for state to be preserved in this case:
chkconfig foo off
rpm -e foo
rpm -i foo-1-1.rpm
Actually, I was only thinking about this case:
chkconfig --del foo
rpm -U foo*.rpm # or "yum update foo"
Whatever the state, it is obviously lost across such a sweeping change
like "rpm -e foo; rpm -i foo*.rpm". One cannot reasonably ask for the
state to be preserved in that case.
An upgrade, though, is different.
I like Michael's idea. "rpm -i" should run chkconfig and do whatever is
appropriate to enable/disable the service on certain runlevels, that's
fine and natural. But "rpm -U" should do nothing in that regard.
After all (I apologize for repeating it over and over again, but I think
it's a crucial point), whatever the situation before the upgrade, it was
very likely the result of a decision made and an action carried by the
human operator. The software should not treat it lightly.
I will also have to verify if it's true that certain cronjobs re-enable
services that were deleted with chkconfig. That's potentially another
source of issues.
--
Florin Andrei
http://florin.myip.org/
12:40 p.m.
New subject: bad practice: not reading the manpage
On Tue, Jun 14, 2005 at 10:14:25AM -0700, Florin Andrei wrote:
After all (I apologize for repeating it over and over again, but I
think
it's a crucial point), whatever the situation before the upgrade, it was
very likely the result of a decision made and an action carried by the
human operator. The software should not treat it lightly.
I disagree. This is *exactly* the same case as if the user has done
rm -f /bin/ls
When you upgrade coreutils, it'll fix this by putting /bin/ls back.
(Note the correspondence between rm and del -- pretty much the same thing.)
It's more consistent for packages to keep doing what they're doing, and for
sysadmins to properly use 'chkconfig off'. You're solving the wrong problem.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 81 degrees Fahrenheit.
1 p.m.
New subject: bad practice: not reading the manpage
On Tue, 2005-06-14 at 13:40 -0400, Matthew Miller wrote:
On Tue, Jun 14, 2005 at 10:14:25AM -0700, Florin Andrei wrote:
> After all (I apologize for repeating it over and over again, but I think
> it's a crucial point), whatever the situation before the upgrade, it was
> very likely the result of a decision made and an action carried by the
> human operator. The software should not treat it lightly.
I disagree. This is *exactly* the same case as if the user has done
rm -f /bin/ls
When you upgrade coreutils, it'll fix this by putting /bin/ls back.
Oh, come on, how could that be similar? The example is so wrong, I'm not
even sure how to approach it.
/bin/ls is part of the coreutils package as a fixed, unchangeable
component. "Fixed" with regard to sysadmin's actions. You're not
supposed to mangle /bin/ls or similar parts of the package, you are
supposed to let RPM deal with that.
I.e., don't blindly do a "make; make install" in the coreutils source
tree if you have an idea of how to improve the /bin/ls executable, but
you're supposed to create a package and do an update "properly".
The symlinks in /etc/rc*.d however, those are a different story. You are
allowed to make changes. They're similar to config files.
The user should normally not make changes to the binary files,
executables, libraries, etc. and, if changes are made, the package
manager is entitled to fix them, as you correctly point out.
However, runlevel symlinks, config files, etc. are supposed to be
subject to changes by the user/sysadmin. The package manager should not
overrule those changes.
Case in point, often the config files are left unchaged after a package
upgrade, in order to preserve whatever modifications were made by the
user. /etc/rc*.d symlinks are the same, since their state is often the
result of actions taken by the sysadmin.
To let RPM overrule the sysadmin's decisions w.r.t. those symlinks is
like letting RPM blindly overwrite config files during "rpm -U" and not
save backups of the old files.
--
Florin Andrei
http://florin.myip.org/
1:15 p.m.
New subject: bad practice: not reading the manpage
On Tue, Jun 14, 2005 at 11:00:57AM -0700, Florin Andrei wrote:
/bin/ls is part of the coreutils package as a fixed, unchangeable
component. "Fixed" with regard to sysadmin's actions. You're not
supposed to mangle /bin/ls or similar parts of the package, you are
supposed to let RPM deal with that.
And you're not supposed to run chkconfig --del either. (Just 'cause you
*can* doesn't mean you *should*.)
The symlinks in /etc/rc*.d however, those are a different story. You
are
allowed to make changes. They're similar to config files.
Sure. Maybe /bin/ls is bad example, so let's pick another:
If I delete /etc/prelink.conf, I'd expect it to come back when I did an
upgrade.
To let RPM overrule the sysadmin's decisions w.r.t. those
symlinks is
like letting RPM blindly overwrite config files during "rpm -U" and not
save backups of the old files.
And, if I modify /etc/prelink.conf, I *do* get a backup. In fact, I get an
.rpmnew file. That's the proper behavior. Likewise, if I properly use
chkconfig off instead of deleting the configuration information completely,
my configuration is preserved.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 81 degrees Fahrenheit.
12:58 p.m.
New subject: bad practice: not reading the manpage
On Tue, Jun 14, 2005 at 10:14:25AM -0700, Florin Andrei wrote:
I like Michael's idea. "rpm -i" should run chkconfig
and do whatever is
appropriate to enable/disable the service on certain runlevels, that's
fine and natural. But "rpm -U" should do nothing in that regard.
After all (I apologize for repeating it over and over again, but I think
it's a crucial point), whatever the situation before the upgrade, it was
very likely the result of a decision made and an action carried by the
human operator. The software should not treat it lightly.
This would violate rpm's behavior as described by the manpage:
"This upgrades or installs the package currently installed to a newer
version. This is the same as install, except all other version(s) of
the package are removed after the new package is installed."
The current behavior is that "rpm -U" is exactly the same as "rpm -i"
if
the package is not currently installed. (If you want to not install it
if it's not currently installed, then you use "rpm -F".) I really
can't
agree with changing that behavior.
If you mean that it should only be added if it's actually being upgraded,
as opposed to whenever "rpm -U" is run, then I still have the other
objection mentioned in this thread; i.e., chkconfig --del <service>
is quite similar to "rm -f /path/to/file", and you probably don't want
"rpm -U" to not re-add files which were deleted by the operator.
(Although again you might, I suppose.)
John Thacker
10:09 p.m.
On Mon, Jun 13, 2005 at 07:53:07PM -0700, Florin Andrei wrote:
Why "--del" should be different from "off"? In
either case, the package
should not change the state of the service, period. It's not like
something goes off every once in a blue moon and changes things around -
if there's a change, most likely someone made a decision and did it for
a reason. The software should respect that decision.
Because "del" removes the state information completely. Then, when the
package is updated, it has no idea if it was supposed to be on or off, and
has to go with the default. And the default for some of these things
(syslog, say) *should* be "on".
Almost always, it's preferable to disable services with
"--del",
therefore keeping the list shorter and easier to read for the overworked
sysadmin. It's kind of hard to scan tons of chkconfig lists on many
systems, trying to figure out which ones are on and which are off; those
lists are not easy to read at a glance.
chkconfig --list|grep [35]:on
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 81 degrees Fahrenheit.
11:20 p.m.
My POV:
The way FC and RHEL are shipped now, once installed, every service has
either an S or K link in eachj runlevel. Extras should continue that
behavior, for consistency.
chkconfig --add is only for package install scripts.
chkconfig --del is only for package uninstall scripts.
'chkconfig foo on' is for users and package install scripts for the very
few packages that need to be on by default.
'chkconfig foo off' is for users and package install scripts for most
services.
Anyone disagree?
Mike
7:04 p.m.
'chkconfig foo off' is for users and package install scripts
for most
services.
Anyone disagree?
AFAIK 'off' and 'on' should never be necessary in an install script.
The "#chkconfig:" comment at the top of each service's init script
specifies which runlevels it is on-by-default in (or '-' if it is
always off-by-default).
On a related note, to check on the current behavior of FC scripts, I
pulled all of the FC4 (no extras or third-party) install/uninstall
scripts out of the fedoratracker.org database and did some grepping.
There are lots of --add and --del instances, but no 'on' or 'off'
commands, so I think FC already complies with a reasonable standard.
I'm guessing, then, that the OP is either using --del when 'off' would
be more appropriate or using third-party RPMs that do things they
oughtn't in the scripts.
--Brad
9:09 p.m.
On Mon, 2005-06-13 at 19:02 -0700, Florin Andrei wrote:
Something that absolutely needs to be fixed in future FC versions is
services that "misteriously" re-enable themselves.
Anyway, I will be very happy to follow said policy, since myself I'm
guilty of building RPM packages that do stupid things with chkconfig. I
hereby repent and publicly admit my sinful ways, and I ask everyone to
work together and come up with a clear, better way of dealing with this
class of problems.
Otherwise... you know, software that thinks itself smarter than its
users - that's so Microsoft.
could you make a list of the ones you find and file bugs?
otherwise we might not know it's causing a problem.
thanks
-sv
9:26 p.m.
--On Monday, June 13, 2005 10:09 PM -0400 seth vidal <skvidal(a)phy.duke.edu>
wrote:
could you make a list of the ones you find and file bugs?
And perhaps post the list here. I'd be interested in knowing which ones do
that, and in some cases I can generate patches.
I've noticed that this is a common difference between RH packages and those
generated from upstream tarballs, with the upstream packages tending to
turn things on and the RH spec files tweaked to not do so.
6892
days inactive
6895
days old
22 comments
10 participants
participants (10)
-
Bill Nottingham -
Brad Smith -
Florin Andrei -
John Thacker -
Kenneth Porter -
Matthew Miller -
Michael A. Peters -
Mike MacCana -
seth vidal -
Tim Waugh