You are not logged in.

#1 2018-07-11 17:03:26

alodyne
Member
Registered: 2018-07-11
Posts: 4

Corrupted man-db on similar installations, resists package reinstalls

I had used two very similar Arch installations daily for about six months, keeping both updated independently and doing pretty well with maintenance. In May and June I had to work on a project that kept me in Windows and away from my (virtual) Arch environments. I returned and upgraded both systems. Afterward, I noticed higher than usual usage readings on one and saw a long-running mandb process.

I discovered by running mandb -t that I have some corrupted database problems. The output of mandb -t on one system is here. I tried using pacman -Scc to remove the cache and reinstalling all packages indicated by pacman -Qo on the files listed in the errors:

pacman -S numactl openmpi mjpegtools pcre pcre2 gnutls shadow dos2unix cdparanoia

This had no effect on the output of mandb -t. The other system was the same, except without the mjpegtools, dos2unix, and cdparanoia packages.

Everything seems to be working on both systems. I haven't had any difficulty or error message yet, just the error messages when mandb is run by hand or by cron.weekly.

I will be very grateful for any assistance.

Offline

#2 2018-07-11 17:15:00

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: Corrupted man-db on similar installations, resists package reinstalls

Welcome to the arch linux forums alodyne.  If you install mjpegtools, dos2unix, and cdparanoia on the other system does that then produce warnings from mandb for those packages?

Offline

#3 2018-07-11 18:42:07

alodyne
Member
Registered: 2018-07-11
Posts: 4

Re: Corrupted man-db on similar installations, resists package reinstalls

loqs wrote:

Welcome to the arch linux forums alodyne.  If you install mjpegtools, dos2unix, and cdparanoia on the other system does that then produce warnings from mandb for those packages?

Thank you. Yes, warnings are produced that pertain to dos2unix. Here is the updated mandb -t output. (Note that all packages and their dependencies installed via pacman -S without error.)

Offline

#4 2018-07-11 22:38:06

seth
Member
Registered: 2012-09-03
Posts: 49,992

Re: Corrupted man-db on similar installations, resists package reinstalls

Part of those errors stem from another running mandb process (check?)
About the missing files: some NoExtract setting in pacman.conf?

Offline

#5 2018-07-12 16:29:08

alodyne
Member
Registered: 2018-07-11
Posts: 4

Re: Corrupted man-db on similar installations, resists package reinstalls

seth wrote:

Part of those errors stem from another running mandb process (check?)
About the missing files: some NoExtract setting in pacman.conf?

Ah, thank you. Yes, I just happened to be trying this when the automated process started. I misspoke above, it is not cron but a systemd timer that runs mandb. Every six hours seems excessive but I can worry about that later. Here is my pacman.conf. (It doesn't have any NoExtract directives.)

Last edited by alodyne (2018-07-12 16:29:29)

Offline

#6 2018-07-12 18:37:58

seth
Member
Registered: 2012-09-03
Posts: 49,992

Re: Corrupted man-db on similar installations, resists package reinstalls

'key. Let's randomly inspect one of the failures (though an updated log from a non-colliding run would be good):

stat /usr/share/man/man1/mjpegtools.1.gz
file /usr/share/man/man1/mjpegtools.1.gz
whatis /usr/share/man/man1/mjpegtools.1.gz
md5sum /usr/share/man/man1/mjpegtools.1.gz
pacman -Qo /usr/share/man/man1/mjpegtools.1.gz
pacman -Qkk mjpegtools

Offline

#7 2018-07-12 21:13:09

alodyne
Member
Registered: 2018-07-11
Posts: 4

Re: Corrupted man-db on similar installations, resists package reinstalls

Before I paste the results of your commands, I tried again to run mandb -t without collisions. But during the run, I had top open in another window and noticed that there were up to 4 mandb processes going. They all ended when the one I started finished. So I tried again. I verified that no mandb processes were running, then did:

$ sudo mandb -t
$ top -c -p $(pgrep -d',' -f "mandb") # paste of top output follows

top - 15:06:35 up 17 min,  1 user,  load average: 1.81, 1.09, 0.69
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
%Cpu(s): 41.1 us, 33.2 sy,  0.0 ni, 15.1 id,  0.0 wa,  7.6 hi,  2.9 si,  0.0 st
MiB Mem :   3947.6 total,   2368.6 free,    766.9 used,    812.1 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   3152.9 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                 
 4227 root      20   0   31380   9132   2732 S   7.0   0.2   0:02.76 mandb -t                                
 4226 root      20   0   78144   5936   4964 S   0.0   0.1   0:00.00 sudo mandb -t

Perhaps this is normal behavior, I'm afraid I don't know. Sorry if this is obvious. The result is not much different, still with the "resource temporarily unavailable" complaints, so I imagine it is not normal. In case it matters, I shutdown the VM and restarted between my last post and this one.

Here are the pastes of the commands you suggested.

seth wrote:

'key. Let's randomly inspect one of the failures (though an updated log from a non-colliding run would be good):

$ stat /usr/share/man/man1/mjpegtools.1.gz

  File: mjpegtools.1.gz
  Size: 37510     	Blocks: 80         IO Block: 4096   regular file
Device: 803h/2051d	Inode: 2260899     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-07-12 14:54:26.342667716 -0600
Modify: 2016-08-07 13:23:20.448971979 -0600
Change: 2018-07-11 10:48:44.855037381 -0600
 Birth: -

$ file /usr/share/man/man1/mjpegtools.1.gz

mjpegtools.1.gz: gzip compressed data, max compression, from Unix, original size 110394

$ whatis /usr/share/man/man1/mjpegtools.1.gz

mjpegtools.1.gz: nothing appropriate.

$ md5sum /usr/share/man/man1/mjpegtools.1.gz

b97d2cccd85ac8f11d2fc7fc2dc7beb1  /usr/share/man/man1/mjpegtools.1.gz

$ pacman -Qo /usr/share/man/man1/mjpegtools.1.gz

/usr/share/man/man1/mjpegtools.1.gz is owned by mjpegtools 2.1.0-3

$ pacman -Qkk mjpegtools

mjpegtools: 171 total files, 0 altered files

Offline

#8 2018-07-13 07:02:52

seth
Member
Registered: 2012-09-03
Posts: 49,992

Re: Corrupted man-db on similar installations, resists package reinstalls

The outputs for the mjpegtools checks are all fine and I checked running mandb sudo wrapped, it creates the second process here as well and I actually also get all those errors. They also show on an instance ran by root, so they#re most likely jsut false positives by "-t" (the test run is not supposed to update the databse)
=> red herring.

mandb takes some time and is run daily by a systemd timer. Sure there's an actual problem?

Offline

Board footer

Powered by FluxBB