Bug 1177993 - "man -k" gives always empty results; reason: mandb.timer is disabled after kickstart installation
Summary: "man -k" gives always empty results; reason: mandb.timer is disabled after ki...
Alias: None
Product: Fedora
Classification: Fedora
Component: man-db
Version: 22
Hardware: Unspecified
OS: Linux
Target Milestone: ---
Assignee: Nikola Forró
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2015-01-01 06:37 UTC by Edgar Hoch
Modified: 2016-07-19 19:55 UTC (History)
4 users (show)

Fixed In Version: man-db-
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-07-19 19:32:09 UTC
Type: Bug

Attachments (Terms of Use)
Patch for mandb.spec (427 bytes, patch)
2015-01-01 06:37 UTC, Edgar Hoch
no flags Details | Diff

Description Edgar Hoch 2015-01-01 06:37:51 UTC
Created attachment 974927 [details]
Patch for mandb.spec

Description of problem:
After a fresh kickstart installation of Fedora 21, "man -k mansearchstring" is not working. The output is always empty, regardless which argument mansearchstring is used. But I think the command should work on every system with installed manpages.

The reason is that /var/cache/man/ is empty.

Why is /var/cache/man/ empty?

The package man-db which was released up to and including Fedora 20 contains the file /etc/cron.daily/man-db.cron which lets crond to run mandb every day. mandb fills and updates /var/cache/man/ which are neccessary for "man -k" to work.

The package man-db of Fedora 21 is missing this cron configuration file. Instead, it contains the files /usr/lib/systemd/system/mandb.service and /usr/lib/systemd/system/mandb.timer . This means that mandb should be run by systemd instead of crond on Fedora 21.

The problem is that after installation with kickstart mandb.timer is disabled.

I found two possible reasons why mandb.timer is disabled:

Package man-db contains postinstall and preuninstall scripts that enable and start od stop and disable mandb.timer:

# rpm -q --scripts man-db
postinstall scriptlet (using /bin/sh):
/usr/bin/rm -rf /var/cache/man/*
# enable and start timer
rpm -q systemd > /dev/null
if [ "$?" -eq 0 ]; then
    systemctl -q enable mandb.timer
    systemctl start mandb.timer
preuninstall scriptlet (using /bin/sh):
# stop and disable timer
rpm -q systemd > /dev/null
if [ "$?" -eq 0 ]; then
    if [ "$1" -eq 0 ]; then
        systemctl stop mandb.timer
        systemctl -q disable mandb.timer

Package man-db was installed during kickstart installation.
But /var/log/anaconda/packaging.log tells that man-db was installed before systemd:

05:12:11,015 INFO packaging: man-db- (2796/7026)
05:12:11,022 INFO packaging: systemd-216-12.fc21.x86_64 (2862/7026)

I don't know the details of the context while kickstart installation but would it be possible that the systemctl commands in postinstall have no effect in this context?
I know that any "systemctl start" command does not work while kickstart installation.
I don't know if a "systemctl enable" command would be working while in kickstart installation, but if it would do in principle, doesn't it require the systemd package because it contains the systemctl command?

Hence I think that the rpm spec file should contain at least the following lines, to ensure that systemd is installed before man-db:

BuildRequires: systemd-units
Requires(post): systemd-units
Requires(preun): systemd-units

Next: /usr/lib/systemd/system/mandb.timer contains the line


There exists no file
/usr/lib/systemd/system/multi-user.target.wants/mandb.timer -> ../mandb.timer .

If I understand the manpage of systemd.unit right, then only the WantedBy declaration or the file in the .wants directory is neccessary.

But after kickstart installation the dependeny is not known:

# systemctl --reverse list-dependencies mandb.timer

But when I reinstall the package, then the system knows the dependency:

# yum -y reinstall man-db
# systemctl --reverse list-dependencies mandb.timer
● └─multi-user.target
●   └─graphical.target
# systemctl status mandb.timer
● mandb.timer - Daily man-db cache update
   Loaded: loaded (/usr/lib/systemd/system/mandb.timer; enabled)
   Active: active (waiting) since Do 2015-01-01 05:58:22 CET; 1h 26min ago

I think that this problem will be solved too if it will be required that systemd is installed before man-db. But this has to be proven with an updated package.

Version-Release number of selected component (if applicable):
Fedora 21

How reproducible:

Steps to Reproduce:
1. Install Fedora 21 using kickstart which requires package man-db.
2. Reboot an check the results:
# systemctl status mandb.timer
# systemctl --reverse list-dependencies mandb.timer
# ls -l /var/cache/man/

Actual results:
mandb.timer is disabled.
No dependency on other units.
/var/cache/man/ is empty.

Expected results:
mandb.timer is enabled.
No dependency on (at least) multi-user.target.
/var/cache/man/ is not empty. (But note: mandb will run for a while, so the directory may be still empty immediate after the first reboot. If the mandb.timer is enabled, check the directory later again.)

Comment 1 Fedora Update System 2015-01-05 15:41:27 UTC
man-db- has been submitted as an update for Fedora 21.

Comment 2 Fedora Update System 2015-01-06 06:09:19 UTC
Package man-db-
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing man-db-'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 3 lnie 2015-01-06 07:58:47 UTC
man-db- works

Comment 4 Fedora Update System 2015-01-17 05:43:34 UTC
man-db- has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 5 Marcel Holtmann 2015-05-29 14:52:09 UTC
Converting back to crontabs is not a fix. If the timer unit does not start, then that should be fixed.

Comment 6 Fedora Admin XMLRPC Client 2015-07-13 10:31:43 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Fedora End Of Life 2015-11-04 11:12:09 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 8 Fedora End Of Life 2016-07-19 19:32:09 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 9 Edgar Hoch 2016-07-19 19:55:14 UTC
I am not sure if this is fixed, because package man-db-2.7.5-3.fc24.x86_64 doesn't contain any systemd unit files. But "man -k mansearchstring" is working on Fedora 23 and 24 after kickstart installation, so I think we can leave this bug closed.

Note You need to log in before you can comment on or make changes to this bug.