Yum update lock issue

asterisk
freepbx
Tags: #<Tag:0x00007fafc55e05e8> #<Tag:0x00007fafc55e4468>

(Danny) #1

I have not updated for a year. SHowed 290 RPM to update so I told it to run the update in the UI

It has been 25 mins and I have the same message repeating itself.

What do I do? Wait and it will unlock as it finishes all the update or kill 21747, how?
runing kill 21747 does not kill the hung PID when I run grep yum again it is still there

Loaded plugins: fastestmirror, versionlock
Existing lock /var/run/yum.pid: another copy is running as pid 21747.
Another app is currently holding the yum lock; waiting for it to exit…
The other application is: yum
Memory : 140 M RSS (540 MB VSZ)
Started: Fri Jan 24 19:32:21 2020 - 10:01 ago
State : Sleeping, pid: 21747

±--------------------±-----------±--------±------------+
| Module | Version | Status | License |
±--------------------±-----------±--------±------------+
| accountcodepreserve | 13.0.2.2 | Enabled | GPLv2 |
| amd | 13.0.2 | Enabled | GPLv3+ |
| announcement | 13.0.7.3 | Enabled | GPLv3+ |
| areminder | 14.0.4.2 | Enabled | Commercial |
| arimanager | 13.0.4 | Enabled | GPLv3+ |
| asterisk-cli | 14.0.1 | Enabled | GPLv3+ |
| asteriskinfo | 13.0.7.1 | Enabled | GPLv3+ |
| backup | 14.0.10.1 | Enabled | GPLv3+ |
| blacklist | 14.0.1 | Enabled | GPLv3+ |
| broadcast | 14.0.1.10 | Enabled | Commercial |
| builtin | | Enabled | |
| bulkhandler | 13.0.14.7 | Enabled | GPLv3+ |
| calendar | 14.0.2.9 | Enabled | GPLv3+ |
| callback | 13.0.5.3 | Enabled | GPLv3+ |
| callerid | 13.0.8.13 | Enabled | Commercial |
| callforward | 14.0.1.3 | Enabled | AGPLv3+ |
| calllimit | 13.0.5.5 | Enabled | Commercial |
| callrecording | 14.0.5 | Enabled | AGPLv3+ |
| callwaiting | 14.0.1.1 | Enabled | GPLv3+ |
| cdr | 14.0.5.14 | Enabled | GPLv3+ |
| cel | 14.0.2.8 | Enabled | GPLv3+ |
| certman | 14.0.3.1 | Enabled | AGPLv3+ |
| cidlookup | 14.0.1.7 | Enabled | GPLv3+ |
| conferences | 13.0.23.12 | Enabled | GPLv3+ |
| conferencespro | 14.0.2.5 | Enabled | Commercial |
| configedit | 13.0.7.1 | Enabled | AGPLv3+ |
| contactmanager | 14.0.4.12 | Enabled | GPLv3+ |
| core | 14.0.18.37 | Enabled | GPLv3+ |
| cos | 13.0.12.2 | Enabled | Commercial |
| customappsreg | 13.0.5.4 | Enabled | GPLv3+ |
| cxpanel | 14.0.1 | Enabled | GPLv3 |
| dahdiconfig | 14.0.1.3 | Enabled | GPLv3+ |
| dashboard | 14.0.5.1 | Enabled | AGPLv3+ |
| daynight | 14.0.1 | Enabled | GPLv3+ |
| dictate | 13.0.5 | Enabled | GPLv3+ |
| directory | 13.0.19.5 | Enabled | GPLv3+ |
| disa | 13.0.6.6 | Enabled | AGPLv3+ |
| donotdisturb | 14.0.1.1 | Enabled | GPLv3+ |
| endpoint | 14.0.2.188 | Enabled | Commercial |
| extensionroutes | 13.0.10.7 | Enabled | Commercial |
| fax | 14.0.2.6 | Enabled | GPLv3+ |
| faxpro | 14.0.4 | Enabled | Commercial |
| featurecodeadmin | 13.0.6.4 | Enabled | GPLv3+ |
| findmefollow | 14.0.1.20 | Enabled | GPLv3+ |
| firewall | 13.0.57.1 | Enabled | AGPLv3+ |
| framework | 14.0.5.5 | Enabled | GPLv2+ |
| freepbx_ha | 13.0.11 | Enabled | Commercial |
| hotelwakeup | 14.0.1.4 | Enabled | GPLv2 |
| iaxsettings | 14.0.1.4 | Enabled | AGPLv3 |
| infoservices | 13.0.1.3 | Enabled | GPLv2+ |
| irc | 2.11.0.7 | Enabled | GPLv3+ |
| ivr | 14.0.4 | Enabled | GPLv3+ |
| languages | 14.0.1.2 | Enabled | GPLv3+ |
| logfiles | 13.0.10.5 | Enabled | GPLv3+ |
| manager | 13.0.2.5 | Enabled | GPLv2+ |
| miscapps | 13.0.3.1 | Enabled | GPLv3+ |
| miscdests | 13.0.5 | Enabled | GPLv3+ |
| music | 13.0.22.4 | Enabled | GPLv3+ |
| oembranding | 14.0.9.35 | Enabled | Commercial |
| outroutemsg | 13.0.2.1 | Enabled | GPLv3+ |
| paging | 14.0.6 | Enabled | GPLv3+ |
| pagingpro | 14.0.2.12 | Enabled | Commercial |
| parking | 13.0.19.8 | Enabled | GPLv3+ |
| parkpro | 14.0.2.6 | Enabled | Commercial |
| phpinfo | 13.0.2 | Enabled | GPLv2+ |
| pinsets | 13.0.10 | Enabled | GPLv3+ |
| pinsetspro | 13.0.9.13 | Enabled | Commercial |
| pm2 | 13.0.5 | Enabled | AGPLv3+ |
| pms | 14.0.2.25 | Enabled | Commercial |
| presencestate | 14.0.1.7 | Enabled | GPLv3+ |
| printextensions | 13.0.3.1 | Enabled | GPLv3+ |
| queueprio | 13.0.2 | Enabled | GPLv3+ |
| queues | 14.0.2.22 | Enabled | GPLv2+ |
| queuestats | 14.0.1.22 | Enabled | Commercial |
| qxact_reports | 14.0.7.11 | Enabled | Commercial |
| recording_report | 14.0.1.25 | Enabled | Commercial |
| recordings | 13.0.30.12 | Enabled | GPLv3+ |
| restapi | 13.0.21.1 | Enabled | AGPLv3 |
| restapps | 13.0.92.23 | Enabled | Commercial |
| ringgroups | 14.0.1.5 | Enabled | GPLv3+ |
| sangomacrm | 14.0.1.12 | Enabled | Commercial |
| setcid | 13.0.6.2 | Enabled | GPLv3+ |
| sipsettings | 14.0.27.5 | Enabled | AGPLv3+ |
| sipstation | 14.0.1.8 | Enabled | Commercial |
| sms | 14.0.4.5 | Enabled | Commercial |
| soundlang | 14.0.5 | Enabled | GPLv3+ |
| superfecta | 14.0.7 | Enabled | GPLv2+ |
| sysadmin | 14.0.22 | Enabled | Commercial |
| timeconditions | 14.0.2.17 | Enabled | GPLv3+ |
| tts | 13.0.10 | Enabled | GPLv3+ |
| ttsengines | 13.0.7.3 | Enabled | AGPLv3 |
| ucp | 14.0.2.10 | Enabled | AGPLv3+ |
| userman | 14.0.3.44 | Enabled | AGPLv3+ |
| vega | 14.0.3.10 | Enabled | Commercial+ |
| vmblast | 13.0.8 | Enabled | GPLv3+ |
| vmnotify | 14.0.1.1 | Enabled | Commercial |
| voicemail | 14.0.3 | Enabled | GPLv3+ |
| voicemail_report | 13.0.13.3 | Enabled | Commercial |
| vqplus | 14.0.1.18 | Enabled | Commercial |
| weakpasswords | 13.0.2 | Enabled | GPLv3+ |
| webcallback | 13.0.11.2 | Enabled | Commercial |
| webrtc | 14.0.3.7 | Enabled | GPLv3+ |
| xmpp | 14.0.1.15 | Enabled | AGPLv3 |
| zulu | 14.0.56.4 | Enabled | Commercial |
±--------------------±-----------±--------±------------+


(Franck Danard) #3

Hi
What happens after reboot?
yum is still locked?
Why not, you could try to kill yum process as well. and launch :
# yum update yum -y
next
# yum update -y

Just an idea like that.


(Danny) #4

I did not reboot yet. Was waiting to see if anybody ran into a similar situation.
After I run kill {PID} yum is still running


(Dave Burgess) #5

kill -9 {PID} is probably going to get your process knocked down. Once you do that, you may still need to clear out the lock file.

Rebooting would do both, but that’s killing flies with a cannon.


(Danny) #6

How do I clear the locked file after a kill -9?


(Danny) #7

Another question is why did running a system update via GUI cause this and how will I prevent it from happening again on next try as Zulu is acting up and need to upgrade to see if that resolves it


(Dave Burgess) #8

IIRC, yum will clear the file if the locked process is gone, so you should be good to go. If not, the program will tell you where the lock file is.

It happens. The GUI launches the yum update and let’s it run.


(Danny) #9

So should I tell it to try the same thing again and update all 290 RPM after I kill and confirm file is not locked?


(Danny) #10

I killed that with -9 and it seemed its trying to continue where it left off but now yum jobs are hung again for the last 45 mins.


(Dave Burgess) #11

Some of Yum’s updates are big - really big. Do you know which one it’s “locking up” on?

You might want to try logging into the console as ‘root’ and doing your ‘yum -y update’ from the command line.


(Danny) #12

now its stuck on -y install XactViewServerV3 before this it was hung on the image in the screenshot

It is there 4 times. See screenshot


#13

From your shell, see if there is any changes going on

watch -d ‘ps -aux|grep yum’

Edit , sorry formatting error , you need to add quotes


(Danny) #14

Nothing shows when I enter that, just a green box then goes to a green outlined box


(Danny) #15

Seems there is no changes as nothing shows for the command watch -d ‘ps -aux|grep yum’


#16

Add ‘-n 600’ to the watch , it will show any changes in the last 600 seconds. If yum is still not progressing, try updating the modules one by one (with 200 odd I would script it :wink: ).


(Danny) #17

@dicko dicko want to get hired to fix this issue and then update our box and our warm spare off hours? Phone lines close every night at 6pm PST. danny@precisemri.com for details


#18

Not appropriate here :wink: . I would start with


(Danny) #19

I thought the GUI handled it all regardless of the amount of updates. I guess more frequent updates are in order to avoid these issues


(system) closed #20

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.