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 (2022-10-29 01:43:07)
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