"man init" reports MX init is systemd? [SOLVED]

[BitJam]

@tim, did you update any packages? It seems unlikely our installer would do this. Does "sudo find / -name "init.?.gz" turn up more than one file? Does "man /usr/share/man/man8/init.8.gz" give you the correct sysv init man page?

[dolphin_oracle]

@tim, did you update any packages? It seems unlikely our installer would do this. Does "sudo find / -name "init.?.gz" turn up more than one file? Does "man /usr/share/man/man8/init.8.gz" give you the correct sysv init man page?

yes.

[timkb4cq]

No, I didn't update any packages.
It seems to have to do with /var/cache/man/init.db, a file not present running Live.
Deleting that file results in man init returning init 8.
Running sudo mandb -c to recreate it results in man init returning systemd 1

I'm assuming something during installation or first installed run creates that database file.

[BitJam]

The mandb program is run as a cron job. There is /etc/cron.daily/man-db and /etc/cron.weekly/man-db. I have no idea how/why mandb does this switcheroo. In a sane system it would all depend on files under /usr/share/man but this is systemd + Debian.

[timkb4cq]

I believe it indexes all the commands listed in the man pages, and systemd (1) lists init as a command. So does init (8) of course. But systemd cheats and uses the wrong category # for its man page so it shows up first.

Changing the search order in /etc/manpath.config to search 8 before 1 and rebuilding results in man init showing init (8)

[skidoo]

instead of chasing blame, howabout fix0r in /etc/skel/.bashrc and put it to bed

Code: Select all

man() {
    if [[ $@ == "init" ]]; then
        command man telinit
    else
        command ls "$@"
    fi
}

[Old Giza]

Just confirming what was already said, doing "man -d init" shows exactly how man carries out its search. Some extracts:

Code: Select all

...

Succeeded in opening /var/cache/man/index.db O_RDONLY
found 2 names/extensions
multi key lookup (init	1)
multi key lookup (init	8)
Checking physical location: /usr/share/man/man1/systemd.1.gz

ult_src: File /usr/share/man/man1/systemd.1.gz in mantree /usr/share/man
candidate: 1 0 init /usr/share/man /usr/share/man/man1/systemd.1.gz C init 1 1

...

matched: /usr/share/man/man8/init.8.gz
hashtable_free: 1 entries, 1 (100%) unique

ult_src: File /usr/share/man/man8/init.8.gz in mantree /usr/share/man
candidate: 0 0 init /usr/share/man /usr/share/man/man8/init.8.gz A - 8 8
search: 1 0 init /usr/share/man /usr/share/man/man1/systemd.1.gz C init 1 1 (dup: 0)

...
trying a db located file.
name:      init
sec. ext:  1
section:   1
comp. ext: gz
id:        C
mtime:     1483760039.000000000
pointer:   systemd
filter:    -
whatis:    

systemd: relying on whatis refs is deprecated
Checking physical location: /usr/share/man/man1/systemd.1.gz

ult_src: File /usr/share/man/man1/systemd.1.gz in mantree /usr/share/man
found ultimate source file /usr/share/man/man1/systemd.1.gz

There was this possibly relevant Debian bug from when I guess systemd was there but not the default init system? At bottom is this:

Code: Select all

Installing sysvinit-core first, then man-db will give you
/usr/share/man/man1/systemd.1.gz on "man init".

Installing man-db first, then sysvinit-core will give you
/usr/share/man/man8/init.8.gz on "man init".

I think this points at an issue in man-db and some oddities regarding
its index/cache file in /var/cache/man/index.db.

[timkb4cq]

So we have two possible ways to fix this, skidoo's addition to etc/skel/.bashrc

Code: Select all

man() {
    if [[ $@ == "init" ]]; then
        command man telinit
    else
        command ls "$@"
    fi
}

or changing line 111 in /etc/manpath.config from

Code: Select all

SECTION		1 n l 8 3 2 3posix 3pm 3perl 3am 5 4 9 6 7

to

Code: Select all

SECTION		8 1 n l 3 2 3posix 3pm 3perl 3am 5 4 9 6 7

[Jerry3904]

I have the sense that the first would be secure against later upgrades, the second maybe not?

[BitJam]

I don't like either solution. I suggest we just list it as a known bug for now. Changing the order of the sections will alter which man page shows up whenever there is an overlap between section 1 and section 8. IMO we really don't want to do this. Making a change in .bashrc won't work when other shells are used, the current fix won't work when the full path to the man command is used and so forth. The extra confusion this could cause is not worth what is basically a cosmetic fix anyway.

First do no harm. Let's just list this as a known bug for now and move on.

Edit: ISTM the fact that the man page you see changes after mandb runs may be a bug. Perhaps that's the intended behavior but it seems peculiar and surprising. I wonder which other man pages get changed?

Another solution I don't like but still like better than the previous two is to update the cron scripts that call mandb and add a line that erases the one file that causes the problem. This won't impact other man pages and it should work consistently no matter how "man" is called. There is a tiny window of vulnerability between when mandb runs and the file is removed. It will also be vulnerable if mandb is called manually (until the next time the cron job runs). The thing I don't like about this solution is we need our own version of the man package. OTOH, we may need to do this more and more as Debian goes the systemd route and we stay with svsv init.