[SOLVED] urpmi --auto-select hangs on Mageia 5

[merlin]

I have run into an issue that performing an update using the KDE red ! icon on the plasma panel causes the system update to hang.

I rebooted to get a clean start, and tried to manually do a system update as superuser:

Code: Select all

[root@localhost ~]# urpmi.update -a
medium "Core Release (distrib1)" is up-to-date
medium "Core Updates (distrib3)" is up-to-date
medium "Nonfree Release (distrib11)" is up-to-date
medium "Nonfree Updates (distrib13)" is up-to-date
medium "Core 32bit Release (distrib31)" is up-to-date
medium "Core 32bit Updates (distrib32)" is up-to-date
medium "Nonfree 32bit Release (distrib36)" is up-to-date
medium "Nonfree 32bit Updates (distrib37)" is up-to-date
medium "chrome_x86_64" is up-to-date
[root@localhost ~]#
[root@localhost ~]#
[root@localhost ~]# urpmi -v --auto-select
getting lock on urpmi
using mirror http://www.mirrorservice.org/sites/mageia.org/pub/mageia/distrib/5/x86_64
examining synthesis file [/var/lib/urpmi/Core Release (distrib1)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Core Updates (distrib3)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Nonfree Release (distrib11)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Nonfree Updates (distrib13)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Core 32bit Release (distrib31)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Core 32bit Updates (distrib32)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Nonfree 32bit Release (distrib36)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Nonfree 32bit Updates (distrib37)/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/chrome_x86_64/synthesis.hdlist.cz]
getting exclusive lock on rpm


The urpmi -v --auto-select fails to output any further debug and I have to kill the urpmi process using kill -s 9.

Note that Ctrl-C does not terminate the urpmi -v --auto-select suggesting the process has hung on an uninterruptible (signal) system call.

Note that I have been using the 64-bit and 32-bit tainted repros for many months. I tried disabling those repros in case that was the trouble but it seemed to make no difference.

I wonder whether it fails to get the lock on rpm and therefore waits forever ?

Any ideas ?

[merlin]

I ran
strace urpmi -v --auto-select

Code: Select all

open("/var/lib/rpm/.RPMLOCK", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
ioctl(5, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7ffda1c438b0) = -1 ENOTTY (Inappropriate ioctl for device)
lseek(5, 0, SEEK_CUR)                   = 0
fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
write(1, "getting exclusive lock on rpm\n", 30getting exclusive lock on rpm
) = 30
flock(5, LOCK_EX|LOCK_NB)               = 0
getgid()                                = 0
getuid()                                = 0
stat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/var/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/var/lib/rpm", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
rt_sigaction(SIGHUP, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGHUP, {0x7ff82db90e80, [], SA_RESTORER|SA_SIGINFO, 0x7ff831ff7180}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x7ff82db90e80, [], SA_RESTORER|SA_SIGINFO, 0x7ff831ff7180}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {0x7ff82db90e80, [], SA_RESTORER|SA_SIGINFO, 0x7ff831ff7180}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {0x7ff82db90e80, [], SA_RESTORER|SA_SIGINFO, 0x7ff831ff7180}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [], SA_RESTORER, 0x7ff831ff7180}, 8) = 0
open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 6
fstat(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff83334d000
read(6, "MemTotal:        6112720 kB\nMemF"..., 1024) = 1024
close(6)                                = 0
munmap(0x7ff83334d000, 4096)            = 0
futex(0x7ff82e015358, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 6
read(6, "0-1\n", 8192)                  = 4
close(6)                                = 0
umask(022)                              = 022
open("/var/lib/rpm/.dbenv.lock", O_RDWR|O_CREAT, 0644) = 6
umask(022)                              = 022
fcntl(6, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
open("/var/lib/rpm/DB_CONFIG", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/var/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=20480, ...}) = 0
open("/var/lib/rpm/__db.001", O_RDWR|O_CREAT|O_EXCL, 0644) = -1 EEXIST (File exists)
open("/var/lib/rpm/__db.001", O_RDWR)   = 7
fcntl(7, F_GETFD)                       = 0
fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
fstat(7, {st_mode=S_IFREG|0644, st_size=286720, ...}) = 0
read(7, "\227\10\22\0\0\0\0\0\5\0\0\0\3\0\0\0\34\0\0\0\344\325\302\0049\215\351\236\0\0\0\0"..., 160) = 160
lseek(7, 472, SEEK_SET)                 = 472
read(7, "\0`\4\0\0\0\0\0\0\200\20\0\0\0\0\0\377\377\377\377\377\377\377\377", 24) = 24
close(7)                                = 0
open("/var/lib/rpm/__db.001", O_RDWR)   = 7
fcntl(7, F_GETFD)                       = 0
fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
mmap(NULL, 1081344, PROT_READ|PROT_WRITE, MAP_SHARED, 7, 0) = 0x7ff826b9a000
open("/var/lib/rpm/__db.002", O_RDWR|O_CREAT, 0644) = 8
fcntl(8, F_GETFD)                       = 0
fcntl(8, F_SETFD, FD_CLOEXEC)           = 0
mmap(NULL, 253952, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0) = 0x7ff8331f5000
open("/var/lib/rpm/__db.003", O_RDWR|O_CREAT, 0644) = 9
fcntl(9, F_GETFD)                       = 0
fcntl(9, F_SETFD, FD_CLOEXEC)           = 0
mmap(NULL, 1318912, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7ff826a58000
futex(0x7ff8331f5370, FUTEX_WAIT, 2, NULL


Seems the hang is occurring on a futex system call. I suspect the futex call will not be aborted (interrupted) by a Ctrl-C (SIGINT signal).

It is 100% repeatable.

Any ideas ?

[wintpe]

just to let you know your not being ignored, no ideas.

i dont use it, prefer to check and update when it suits me.

regards peter

[merlin]

Seems that
rpm -aq
also hangs.

I wonder whether the rpm database has become corrupted ? How can I check the integrity of the rpm database ?

[doktor5000]

See e.g. https://access.redhat.com/articles/3763 and according to https://unix.stackexchange.com/question ... m-database
rpm --verifydb should also work.

[merlin]

Thanks doktor5000

Code: Select all

[root@localhost rpm]# rpm -vv --verifydb
ufdio:       1 reads,    15649 total bytes in 0.000018 secs
ufdio:       1 reads,     5187 total bytes in 0.000009 secs
D: opening  db environment /var/lib/rpm private:0x401
D: verified db index       Enhancename
D: verified db index       Supplementname
D: verified db index       Suggestname
D: verified db index       Recommendname
D: verified db index       Sha1header
D: verified db index       Sigmd5
D: verified db index       Installtid
D: verified db index       Dirnames
D: verified db index       Triggername
D: verified db index       Obsoletename
D: verified db index       Conflictname
D: verified db index       Providename
D: verified db index       Requirename
D: verified db index       Group
D: verified db index       Basenames
D: verified db index       Name
D: verified db index       Packages
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm


Seems that the rpm database is OK.

I found this webpage:
https://unix.stackexchange.com/question ... g-rpm-file

Code: Select all

ls -al /var/lib/rpm/__db.0*
-rw-r--r-- 1 root root       0 Nov 14  2016 __db.000
-rw-r--r-- 1 root root  286720 Nov 16 09:07 __db.001
-rw-r--r-- 1 root root  157912 Nov 16 09:07 __db.002
-rw-r--r-- 1 root root 1318912 Oct 22 18:37 __db.003


Seems that I have 4 of these database "temporary files".

The webpage said run:
rm -rf /var/lib/rpm/__db.0*

which deleted the 4 database "temporary files".

Now rpm -aq works!!

Hopefully that has fixed my issue. Probably my PC crashed whilst the rpm database was in use which triggered the failure.