Red Hat Bugzilla – Bug 501070
RFE: yum lock message shouldn't show task information by default
Last modified: 2014-01-21 18:09:16 EST
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. thanks, stefan 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
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.
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, stefan
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 :).
Hi, 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.