You are not logged in.
I'm using the systemd timer to update manual pages daily.
/etc/systemd/system/timers.target.wants/man-db.timer
is just a symlink to the standard timer
lrwxrwxrwx 1 root root 36 Chw 10 2019 /etc/systemd/system/timers.target.wants/man-db.timer -> /usr/lib/systemd/system/man-db.timer
This had been working, as far as I know, perfectly. Twice in the last couple of weeks or so, however, something has gone wrong even though systemctl doesn't seem aware of it. That is, systemctl --failed yields no units. systemctl list-timers produces
NEXT LEFT LAST PASSED UNIT ACTIVATES
Sat 2022-03-12 01:02:15 GMT 5min left Sat 2022-03-12 00:00:47 GMT 55min ago fangfrisch.timer fangfrisch.service
Sat 2022-03-12 05:48:30 GMT 4h 52min left Fri 2022-03-11 13:02:55 GMT 11h ago updatedb.timer updatedb.service
Sat 2022-03-12 08:24:11 GMT 7h left Fri 2022-03-11 13:02:55 GMT 11h ago man-db.timer man-db.service
Sat 2022-03-12 15:01:19 GMT 14h left Fri 2022-03-11 03:08:24 GMT 21h ago etckeeper.timer etckeeper.service
Sat 2022-03-12 15:01:19 GMT 14h left Fri 2022-03-11 03:08:24 GMT 21h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sun 2022-03-13 00:00:00 GMT 23h left Sat 2022-03-12 00:00:02 GMT 56min ago logrotate.timer logrotate.service
Sun 2022-03-13 00:00:00 GMT 23h left Sat 2022-03-12 00:00:02 GMT 56min ago pkgfile-update.timer pkgfile-update.service
Sun 2022-03-13 00:00:00 GMT 23h left Sat 2022-03-12 00:00:02 GMT 56min ago shadow.timer shadow.service
Mon 2022-03-14 00:00:00 GMT 1 day 23h left Mon 2022-03-07 00:00:28 GMT 5 days ago paccache.timer paccache.service
Mon 2022-03-14 01:38:53 GMT 2 days left Mon 2022-03-07 00:12:44 GMT 5 days ago fstrim.timer fstrim.service
10 timers listed.
Pass --all to see loaded but inactive timers, too.
But apropos returns no results for anything I've tried including, for example, sysctl and bash.
The first time this happened, I think I triggered the timer immediately, though I'm not positive about that. Certainly, the index was easily restored.
However, now it has happened again. Since I was on battery this time, I didn't initially try triggering the timer as it is AC only.
Running /usr/bin/mandb manually restores the index of manual pages, as expected, but the output is not entirely expected (to me).
/usr/bin/mandb: can't update index cache /var/cache/man/172611: No such file or directory
Updating index cache for path `/usr/share/man/man8'. Wait.../usr/bin/mandb: warning: /usr/share/man/man8/swapoff.8.gz: whatis parse for swapoff(8) failed
/usr/bin/mandb: warning: /usr/share/man/man8/vigr.8.gz: whatis parse for vigr(8) failed
Updating index cache for path `/usr/share/man/man1'. Wait.../usr/bin/mandb: warning: /usr/share/man/man1/lastb.1.gz: whatis parse for lastb(1) failed
/usr/bin/mandb: warning: /usr/share/man/man1/escp2topbm.1.gz: whatis parse for escp2topbm(1) failed
/usr/bin/mandb: warning: /usr/share/man/man1/pamfixtrunc.1.gz: whatis parse for pamfixtrunc(1) failed
Updating index cache for path `/usr/share/man/man3'. Wait.../usr/bin/mandb: warning: /usr/share/man/man3/uuid_generate_random.3.gz: whatis parse for uuid_generate_random(3) failed
/usr/bin/mandb: warning: /usr/share/man/man3/uuid_generate_time.3.gz: whatis parse for uuid_generate_time(3) failed
/usr/bin/mandb: warning: /usr/share/man/man3/uuid_generate_time_safe.3.gz: whatis parse for uuid_generate_time_safe(3) failed
/usr/bin/mandb: warning: /usr/share/man/man3/TimeDate.3pm.gz: whatis parse for TimeDate(3pm) failed
...
Many similar warnings then follow concerning whatis parse failures for other manual pages.
...
Processing manual pages under /usr/local/man...
/usr/bin/mandb: can't update index cache /var/cache/man/oldlocal/172611: No such file or directory
Purging old database entries in /usr/local/texlive/current/texmf-dist/doc/man/...
Processing manual pages under /usr/local/texlive/current/texmf-dist/doc/man/...
99 man subdirectories contained newer manual pages.
25884 manual pages were added.
0 stray cats were added.
0 old database entries were purged.
The journal includes
Maw 10 00:13:03 XXX systemd[1]: Starting Daily man-db regeneration...
Maw 10 00:13:04 XXX systemd[1]: man-db.service: Deactivated successfully.
Maw 10 00:13:04 XXX systemd[1]: Finished Daily man-db regeneration.
...
Maw 11 13:02:55 XXX systemd[1]: Daily man-db regeneration was skipped because of a failed condition check (ConditionACPower=true).
The first 3 lines are for Thursday, when I was on AC.
The last line is for Friday, when I was on battery.
Is it possible that rather than doing nothing at all on battery, the unit is deleting the index (or some crucial thing accessing the index requires) but not regenerating it?
systemctl start man-db.service
As expected, the condition fails as I'm on battery
○ man-db.service - Daily man-db regeneration
Loaded: loaded (/usr/lib/systemd/system/man-db.service; static)
Active: inactive (dead) since Thu 2022-03-10 00:13:04 GMT; 2 days ago
TriggeredBy: ● man-db.timer
Condition: start condition failed at Sat 2022-03-12 01:47:22 GMT; 1min 0s ago
└─ ConditionACPower=true was not met
Docs: man:mandb(8)
Process: 144138 ExecStart=/usr/bin/install -d -o root -g root -m 0755 /var/cache/man (code=exited, status=0/SUCCESS)
Process: 144139 ExecStart=/usr/bin/find /var/cache/man -type f -name *.gz -atime +6 -delete (code=exited, status=0/SUCCESS)
Process: 144140 ExecStart=/usr/bin/mandb --quiet (code=exited, status=0/SUCCESS)
Main PID: 144140 (code=exited, status=0/SUCCESS)
CPU: 616ms
Maw 10 00:13:03 XXX systemd[1]: Starting Daily man-db regeneration...
Maw 10 00:13:04 XXX systemd[1]: man-db.service: Deactivated successfully.
Maw 10 00:13:04 XXX systemd[1]: Finished Daily man-db regeneration.
Maw 11 13:02:55 XXX systemd[1]: Daily man-db regeneration was skipped because of a failed condition check (ConditionACPower=true).
Maw 12 01:47:22 XXX systemd[1]: Daily man-db regeneration was skipped because of a failed condition check (ConditionACPower=true).
And the journal shows the same thing as before.
systemd[1]: Daily man-db regeneration was skipped because of a failed condition check (ConditionACPower=true).
But, this time, apropos bash shows no damage was done. The index wasn't updated, but the old index wasn't destroyed or rendered inaccessible either.
Is there something different about triggering a .service manually and using a timer which could explain the difference? Or should I be looking elsewhere entirely? Obviously something else could be periodically destroying or corrupting the index or whatever, but, right now, I've no idea what.
Last edited by cfr (2024-04-01 14:55:15)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I marked this as resolved, but have discovered it is not.
If man-db.service is triggered by the timer while on battery, the journal says the job is skipped, but the database is entirely or partly erased. In this case, the only man pages remaining were in /usr/local/. The journal has
systemd[1]: Daily man-db regeneration was skipped because of a failed condition check (ConditionACPower=true).
which is fine, but
apropos bash
apropos ls
apropos systemd
return no relevant results. (Unless there happens to be a match in TeX Live's manual pages, which are under /usr/local in my case.)
Starting the service on AC resolves the issue, of course, but why are the cached results even touched when the service is triggered by the timer on battery power? I'm perfectly happy for the service not to run, but I don't want it destroying the existing database.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I have the same issue, and it's slightly annoying.
I think what's happening is:
As you discovered, "man-db.service" (triggered by "man-db.timer") has "ConditionACPower=true", so it only runs on AC power.
Presumably, this means that on our systems, the "man-db.service" unit only runs very rarely since the system usually happens to be on battery power when the timer triggers.
"mandb" stores its DB in /var/cache/man/, and files older than 1 week in that directory are periodically deleted by "systemd-tmpfiles" (see /usr/lib/tmpfiles.d/man-db.conf).
So, we're probably just unlucky, and "mandb" is run less than once a week on our systems. Thus, "systemd-tmpfiles" goes and cleans up the "old" files in /var/cache/man/, and there we go.
For now, I told "systemd-tmpfiles" to delete the files in /var/cache/man/ only after a month by creating the following file:
# /etc/tmpfiles.d/man-db.conf
#
# Default age is 1 week, but man-db.service runs only on AC power; thus, the DB
# is sometimes completely erased by systemd-tmpfiles because mandb happens to
# run less than once a week.
#
# Let's try 4 weeks instead:
d /var/cache/man 0755 root root 4w
That might help since mandb seems to at least run successfully once per month:
$ sudo journalctl -u man-db|grep Finished
Jan 10 02:52:16 gumshoe systemd[1]: Finished Daily man-db regeneration.
Jan 31 00:18:47 gumshoe systemd[1]: Finished Daily man-db regeneration.
Feb 08 02:08:51 gumshoe systemd[1]: Finished Daily man-db regeneration.
Feb 22 11:10:47 gumshoe systemd[1]: Finished Daily man-db regeneration.
Feb 23 20:44:14 gumshoe systemd[1]: Finished Daily man-db regeneration.
Feb 24 03:30:07 gumshoe systemd[1]: Finished Daily man-db regeneration.
If that doesn't help, I might try to just allow "man-db.service" to run on battery power.
Offline
I have the same issue, and it's slightly annoying.
I think what's happening is:
As you discovered, "man-db.service" (triggered by "man-db.timer") has "ConditionACPower=true", so it only runs on AC power.
Presumably, this means that on our systems, the "man-db.service" unit only runs very rarely since the system usually happens to be on battery power when the timer triggers.
"mandb" stores its DB in /var/cache/man/, and files older than 1 week in that directory are periodically deleted by "systemd-tmpfiles" (see /usr/lib/tmpfiles.d/man-db.conf).
So, we're probably just unlucky, and "mandb" is run less than once a week on our systems. Thus, "systemd-tmpfiles" goes and cleans up the "old" files in /var/cache/man/, and there we go.
Ahhhh! That makes perfect sense.
But do we know **why** `systemd-tmpfiles` is configured to delete the cache if it is more than a week old? Under what circumstances is this in any way desirable? The update to the manual pages doesn't depend on prior deletion so I don't see what purpose the deletion serves.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
It makes even less sense as the service already has/d
# Expunge old catman pages which have not been read in a week.
ExecStart=/usr/bin/find /var/cache/man -type f -name *.gz -atime +6 -delete
and mandb defaults to purge and the service doesn't use "-p" leading to https://gitlab.com/man-db/man-db/-/comm … ab7c5e9b55
Something's Denmark in the state of mandb here…
Online
But do we know **why** `systemd-tmpfiles` is configured to delete the cache if it is more than a week old? Under what circumstances is this in any way desirable? The update to the manual pages doesn't depend on prior deletion so I don't see what purpose the deletion serves.
Yeah, I also asked myself that, especially since some of the mandb options suggest that a database can be purged of invalid entries etc. after initially being created.
I don't have an answer, but the systemd-tmpfiles configuration snippet comes from the upstream project, and is not an Arch-specific addition.
I created https://gitlab.com/man-db/man-db/-/issues/36 to try and shed some light on this behavior.
(To me it even looks like systemd-tmpfiles might corrupt the DB when it goes and deletes random files from it, but I'm no expert.)
Offline
Good news, man-db 2.12.1 will fix this issue by reducing the scope of the cleanup to cat pages only (which apparently was the original intent). So, the manual database itself should stay intact in the future, if I understand correctly (and I can remove my workaround from my previous post).
Offline
man-db 2.12.1 is in the repos now and should fix this issue.
Offline