Page 1 of 1
"man init" reports MX init is systemd? [SOLVED]
Posted: Sun Mar 05, 2017 5:50 pm
by Richard
As per the thread in Spanish reported by keos,
I now understand the problem.
It is a bug or an oversight in the "man" system.
Re: "man init" reports that MX init is systemd?
Posted: Sun Mar 05, 2017 5:54 pm
by dolphin_oracle
actually, its not reporting anything. its just the "man" entry for systemd. I'm not sure sysVinit has a man entry.
***edit*** I'm going to back up on that. the link does point to systemd's man page, but not sure that is because sysVinit doesn't have on maybe. At least, not one I can find.
Re: "man init" reports that MX init is systemd?
Posted: Sun Mar 05, 2017 9:06 pm
by cpoakes
You can use man telinit to see information about SYSV init.
Re: "man init" reports that MX init is systemd?
Posted: Sun Mar 05, 2017 9:39 pm
by skidoo
try this: apropos sysv
(FWIW, no matches found for "sys v" nor "sys-v")
On antiX, I get 4 matches (2 of which don't make sense to me).
manfs fs
man filesystems
^---- these describe "sysv" as a "Linux filesystem type". What?
v---- these 2 do contain info related to sysv
man inittab
man sysv-rc-conf
Re: "man init" reports that MX init is systemd?
Posted: Tue Dec 12, 2017 7:26 pm
by newguy
I can confirm the command "man init" is still showing the manual page for systemd, which MX doesn't use. Running "man telinit" brings up the SysV init page.
This should probably be fixed as it gives the mistaken impression MX is using systemd as the default init implementation. SysV init does have its own manual page, but it isn't displayed when running "man init".
I'm guessing this happens because systemd is installed, probably as a dependency for something else. systemd's man page takes priority over SysV's. The SysV man page is in the man8 sub-directory so it's there, but just isn't getting displayed.
Re: "man init" reports that MX init is systemd?
Posted: Tue Dec 12, 2017 8:40 pm
by dolphin_oracle
newguy wrote:I can confirm the command "man init" is still showing the manual page for systemd, which MX doesn't use. Running "man telinit" brings up the SysV init page.
This should probably be fixed as it gives the mistaken impression MX is using systemd as the default init implementation. SysV init does have its own manual page, but it isn't displayed when running "man init".
I'm guessing this happens because systemd is installed, probably as a dependency for something else. systemd's man page takes priority over SysV's. The SysV man page is in the man8 sub-directory so it's there, but just isn't getting displayed.
how does one fix it?
Re: "man init" reports that MX init is systemd?
Posted: Tue Dec 12, 2017 9:23 pm
by BitJam
The "man init" command is working correctly on MX-17.RC1_x64 running live inside of Virtual Box here. It is the same page that "man telinit" produces.
When it is not working correctly maybe an init.?.gz symlink gets created pointing to the systemd.1.gz man page. In MX-17.RC1 the only "init.*.gz" file is the correct sysv init man page which shows up when I run "man init". Maybe this is only a problem on MX systems before MX-17. If it is a problem on MX-17 then when is the problem created? And how?
Re: "man init" reports that MX init is systemd?
Posted: Tue Dec 12, 2017 9:30 pm
by timkb4cq
Different result here. From an installed, unmodified RC1 in VirtualBox
Code: Select all
tim@mx1:~
$ cat /etc/mx-version
MX-17.RC1_x64 Horizon December 10, 2017
tim@mx1:~
$ man init
SYSTEMD(1) systemd SYSTEMD(1)
NAME
systemd, init - systemd system and service manager
SYNOPSIS
systemd [OPTIONS...]
init [OPTIONS...] {COMMAND}
DESCRIPTION
systemd is a system and service manager for Linux operating systems. When run as first
process on boot (as PID 1), it acts as init system that brings up and maintains userspace
services.
For compatibility with SysV, if systemd is called as init and a PID that is not 1, it will
execute telinit and pass all command line arguments unmodified. That means init and
telinit are mostly equivalent when invoked from normal login sessions. See telinit(8) for
more information.
When run as a system instance, systemd interprets the configuration file system.conf and
the files in system.conf.d directories; when run as a user instance, systemd interprets
the configuration file user.conf and the files in user.conf.d directories. See systemd-
system.conf(5) for more information.
OPTIONS
The following options are understood:
Manual page init(1) line 1 (press h for help or q to quit)
Re: "man init" reports that MX init is systemd?
Posted: Tue Dec 12, 2017 9:34 pm
by timkb4cq
However, if I boot up the iso as a LiveUSB in Vbox I do get what you do. So whatever happens, happens during installation.
Re: "man init" reports that MX init is systemd?
Posted: Tue Dec 12, 2017 9:37 pm
by dolphin_oracle
timkb4cq wrote:However, if I boot up the iso as a LiveUSB in Vbox I do get what you do. So whatever happens, happens during installation.
or maybe when man pages get updated.
Re: "man init" reports that MX init is systemd?
Posted: Tue Dec 12, 2017 9:41 pm
by 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?
Re: "man init" reports that MX init is systemd?
Posted: Tue Dec 12, 2017 9:43 pm
by dolphin_oracle
BitJam wrote:@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.
Re: "man init" reports that MX init is systemd?
Posted: Tue Dec 12, 2017 10:06 pm
by 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.
Re: "man init" reports that MX init is systemd?
Posted: Tue Dec 12, 2017 10:14 pm
by 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.
Re: "man init" reports that MX init is systemd?
Posted: Tue Dec 12, 2017 10:47 pm
by 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)
Re: "man init" reports that MX init is systemd?
Posted: Wed Dec 13, 2017 1:27 am
by 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
}
Re: "man init" reports that MX init is systemd?
Posted: Wed Dec 13, 2017 11:27 am
by 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.
Re: "man init" reports that MX init is systemd?
Posted: Wed Dec 13, 2017 12:54 pm
by 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
Re: "man init" reports that MX init is systemd?
Posted: Wed Dec 13, 2017 1:06 pm
by Jerry3904
I have the sense that the first would be secure against later upgrades, the second maybe not?
Re: "man init" reports that MX init is systemd?
Posted: Wed Dec 13, 2017 1:51 pm
by 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.
Re: "man init" reports that MX init is systemd?
Posted: Wed Dec 13, 2017 2:29 pm
by timkb4cq
How about calling mandb from cron with the -s (--no-straycats) switch?
Re: "man init" reports that MX init is systemd?
Posted: Wed Dec 13, 2017 5:58 pm
by Old Giza
If you add a symlink in /usr/share/man/man1 for init.1.gz > /usr/share/man/man8/init.8.gz, then man init gets what you want without even doing a rebuild using mandb. (And you can still do man systemd of course). I'm on MX16, maybe somebody could verify this for MX17.
You can't just use init as the symlink because mandb -t complains of a bogus filename because the filename number does not correspond to the manpage section number.
Re: "man init" reports that MX init is systemd?
Posted: Wed Dec 13, 2017 7:26 pm
by BitJam
Both of those ideas sound good to me! Solving it with a single symlink seems like the least disruptive approach. I wonder what package it should go into? I've been busy elsewhere today.
Re: "man init" reports that MX init is systemd?
Posted: Wed Dec 13, 2017 8:05 pm
by dolphin_oracle
BitJam wrote:Both of those ideas sound good to me! Solving it with a single symlink seems like the least disruptive approach. I wonder what package it should go into? I've been busy elsewhere today.
we've got an odd-ball package for that stuff, mx-system, that is handy for stuff like this. I'll add it there.