PDA

View Full Version : [SOLVED] Stopping Yum and Multiple Login



Faradi
19th October 2012, 07:27 PM
Hello, earlier I got notification that I have a few updates, so I used Apper (GUI) to update but it was so slow I cancel it.

Then I was using yum, but still so slow I cancel and restart my computer.

Anyway, I googled around and found a solution (maybe) on this forum, that is to clear yum and install fastest mirror plugin.

The thing is, looks like right now I get "lock up" from yum, since there is the old process going on. I can't install, I can't clear it. Here is the message:


# yum clean all
Loaded plugins: langpacks, presto, refresh-packagekit
Existing lock /var/run/yum.pid: another copy is running as pid 1239.
Another app is currently holding the yum lock; waiting for it to exit...
The other application is: yum
Memory : 38 M RSS ( 55 MB VSZ)
Started: Sat Oct 20 00:33:53 2012 - 32:22 ago
State : Traced/Stopped, pid: 1239
Another app is currently holding the yum lock; waiting for it to exit...
The other application is: yum
Memory : 38 M RSS ( 55 MB VSZ)
Started: Sat Oct 20 00:33:53 2012 - 32:24 ago
State : Traced/Stopped, pid: 1239
^Z
[7]+ Stopped yum clean all

Notice the 7 stopped lol.

My question is:

1. How do I stop it? I've tried "kill 1239" but still get this message.

2. Out of topic: I made a huge updates earlier (this is a fresh installation) and am using dual boot with windows. Earlier I have three options when I boot, Fedora, some sort of Fedora rescue and Windows. But now after I update I have 4 - 5 options, they are 1 for Windows and the rest are for different versions of Fedora. Is it normal? How / where can I arrange the booting option?

Thanks in advance :)

jpollard
19th October 2012, 08:13 PM
Try bringing it back into the foreground (fg command).

Stopped processes don't respond to external events, so locks created by the suspended process will remain locked.

You can try "kill -9 1239", as -9 is not ignorable, nor can it be caught for processing - so stopped processes should be killable. "kill 1239" sends a terminate (exit signal) but unless the process wakes up, it will not receive the signal.

4-5 options on what? login? grub?

If grub, it may be different kernels. Fedora keeps 3 by default, so if an update gives you an unusable kernel, you can select an earlier one. I keep one more that I know works (a really old one) just so I can have a last chance recovery to fix things.

Faradi
19th October 2012, 08:25 PM
It works, thanks :)

lol, actually, I googled around (more) and found that syntax but I thought "-9" referring to the number of "failed process" (..?) in my case, 7.. or 10 when I found it. So I was using -10 :P

Grub, I think, but yeah, it is during the login (where I can choose between Fedora or Windows. When I chose the one with "Fedora" instead of "Fedora 17.0 -insert version number" looks like it is still take me to the latest installation - as in I don't have to update it like the other day (300 mb of updates).

Thank you, learn more about Linux from your answer :)

marko
19th October 2012, 08:40 PM
Another handy tip, learn and use "pgrep" and "pkill"

'pkill' allows you to kill a process named "process name" ...


pkill <process name>for a concrete example:


pkill yum
The default signal to the process used by pkill is "SIGTERM" which is a bit more clean and graceful than -9 (which is "SIGKILL"), SIGKILL is likely to leave a dangling process lock or badly formatted files (SIGKILL is the last resort for killing a process). You can use a non-default signal via the option, for example


pkill -SIGQUIT <process name>and 'kill -l' can show you what all the valid names are:
(that's "ell" the letter, not "1" the digit)

kill -l
HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM
PROF WINCH POLL PWR SYS RTMIN RTMIN+1 RTMIN+2 RTMIN+3 RTMAX-3 RTMAX-2 RTMAX-1 RTMAX

Which are in increasing signal order with HUP = 1, INT = 2, ... , KILL = 9, ....

The other nice feature of pgrep (which simply finds and shows the PID of named process) and pkill (which also signals them) is they work for any number of processes, if you need to kill all 10 processes called "X" then "pkill X" will get them all

Faradi
19th October 2012, 09:02 PM
Interesting. Thanks marko, good to know there are many alternatives to achieve a certain goal ;)

glennzo
19th October 2012, 09:14 PM
Another handy tip, learn and use "pgrep" and "pkill"

'pkill' allows you to kill a process named "process"
for a concrete example:
or
The default signal to the process used by pkill is "SIGTERM" which is a bit more clean and graceful than -9 (which is "SIGKILL"), SIGKILL is likely to leave a dangling process lock or badly formatted files (SIGKILL is the last resort for killing a process). The other nice feature of pgrep (which simply finds and shows the PID of named process) and pkill (which also signals them) is they work for any number of processes, if you need to kill all 10 processes called "X" then "pkill X" will get them all

We never stop learning here at Fedora Forum. Nice one marko :)

jpollard
19th October 2012, 09:16 PM
SIGTERM is the default for kill. The reason it doesn't work for suspended processes is that the process must be able to receive the signal, which suspended processes cannot do.

You should be able to see most of the names/numbers for signals that are available in the section 7 signal man page (man 7 signal).

There are a number of signals not documented as they are not standardized. (there are 50+ signals, but many are not documented - some for real time functions, some for odd operations...)