Bug 501070 - RFE: yum lock message shouldn't show task information by default
RFE: yum lock message shouldn't show task information by default
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-05-15 15:39 EDT by stefan
Modified: 2014-01-21 18:09 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-15 16:23:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description stefan 2009-05-15 15:39:17 EDT
Description of problem: yum is too verbose when another process also has a lock on the database.not only does the message take up way too many lines ie 7 (try it on 1024x768), it also contains identical information numerous times like the PID number. The first line of the message is more then enough information: Existing lock /var/run/yum.pid: another copy is running as pid 6038. 

For people who use the CLI and know what this actually means this line is more then enough info and the rest is just redundant, for people who don't know what this means the extra info is too complicated anyway besides they will be most likely be using packagekit anyway. a power user knows to ps for PID 6038 and handle the situation, nor is it omho very useful to know how many memory is being used in this case since it is a packamanagement operation.

The information could be useful to some people however so is it not possible to add a "-v" or a "--verbose" flag to YUM to show all this extra info and leave it minimal without? or the ssh way and be more verbose when more v's are added, like -vvvv? i prefer my output clean and simple if i may say so.


Version-Release number of selected component (if applicable): 3.2.22

How reproducible: start (k)packagekit and at the same time run a yum update

Steps to Reproduce:
1. start packagekit
2. launch konsole
3. su -c 'yum update'
Actual results:
[stefan@localhost ~]$ sudo yum update
Loaded plugins: presto, refresh-packagekit      
Existing lock /var/run/yum.pid: another copy is running as pid 6038.
Another app is currently holding the yum lock; waiting for it to exit...
  The other application is: PackageKit                                  
    Memory :  21 M RSS ( 32 MB VSZ)                                     
    Started: Fri May 15 16:11:26 2009 - 01:09 ago                       
    State  : Running, pid: 6038
see also the forum: http://forums.fedoraforum.org/showthread.php?t=221832

Expected results: less information in the konsole

Additional info: none
Comment 1 James Antill 2009-05-15 16:23:17 EDT
The better questions are:

1. Why is PK holding the lock for over a minute?

2. Who are these people that are using yum on the command line, but will be confused about what "Memory" means (or dates and times, I'm not sure which you where complaining about).

...I could drop it down so that yum -q doesn't print it, I guess, but I'm not inclined to do so ... for instance seeing:

  The other application is: BLAH                                  
    Memory :  210 M RSS ( 320 MB VSZ)                                     
    Started: Thu May 14 16:11:26 2009 - 1 day 01:09 ago                       
    State  : Running, pid: 6038

...gives a huge amount of information that isn't there with just "something is holding the lock".
 I'm also not really swayed with "commands need to be unusable and follow the unix tradition", which seems to be the primary desire in the Forum.
Comment 2 stefan 2009-05-15 16:56:16 EDT
well i see your point, but I am root on my system, I use the CLI hence I think one could safely presume I vagualy know what I am doing or otherwise I should be running ubuntu.

the "old" message was not "something" is holding the lock but PID is locking the DB, to me as a "poweruser" all I need to know is the PID of the other process and I can kill -9 it away, why would it bother me that it has been running for 10 minutes and using 10mb of memory, what I meant to say there is that in the case of yum reporting there is another process locking the DB this isnt particularly useful on the CLI (in a default setup without verbosity), and people using packagekit won't get this at all since all they use is the GUI. One of my pc's is 1024x768, this single database locking message in its current form takes up over half the screen.

yum -q might also be an option, although imh that is working the other way around, where people have to turn stuff off they dont want to see, i personally think the system should bother you as little as possible unless you specifically ask for it (-vvv)

and yes i do like the unix tradition :-) not sure what it has to do with the forum and all, i never noticed it there, but lean mean and simple is preferred over big chunks of text (i have doctor watson for that). 

many thanks for replying though,
Comment 3 James Antill 2009-05-15 17:06:40 EDT
But that's the point ... just doing a random kill -9 on anything which might have the rpmdb open is a _really_ bad idea, so knowing a bit of extra information is a significant help on what you should do. Without this message the only sane thing to do IMO is "ps auxwf | fgrep <pid>".

PK has some message that comes out when it hits the yum lock, it may not be as useful but that'd be an RFE over there IMO.

Personally I followed comment #3 on the forum discussion, and am happy to recommend that to other sysadmins who don't want to see this message :).
Comment 4 stefan 2009-05-16 03:46:42 EDT

thanks for the update. i thought i'd post one more follow up before i let this go because I think that probably I did not express myself properly.

I know using a kill -9 on a process is not a good idea in most cases, i never meant to say that i do so .... just that I could if I wanted to, it would be my *choice* to do so.

 and as I posted as a follow up in the forum I totally agree to removing all traces of (k)packagekit and merely use yum myself, one could also use synaptic or make or rpm, that is the beauty of it, there is the *freedom* to choose what to do and how to do it.

I always thought linux in general is all about choice and all about freedom. You stated in your earlier message that you could change this yum behaviour by implementing a -q option to hide it (or a -v option to turn it on perhaps) but that you are not inclined to because you think that I should feel that this way it is showing vital information. And yes you are probably right that it does show vital information, but where is the choice in that, the freedom. would it not be much more fedora like if this behaviour was optional? so that users can choose wether or not to turn it on or off.

I never intended to dispute the fact that what it shows in not useful, it is. just like the fact that packagekit is useful to some and yum-presto is useful, I just would like the ability to choose the way my system behaves.

thanks for exchanging opinions with me about this and carry on the good work.

Note You need to log in before you can comment on or make changes to this bug.