Shows wrong init when using OpenRC about inxi

[GoogleCodeExporter]

For Epoch I copy pasted the wrong output, its actually:

$ ps -e | head -n 2
  PID TTY          TIME CMD
    1 ?        00:00:00 epoch

Original comment by [email protected] on 14 Jan 2015 at 6:12

[GoogleCodeExporter]

Thanks for the complete info, some of this stuff was never tested, and we could 
get no data on the init systems.

These look like easy bugs to fix, should be up soon, I'll let you know.

It's good to see that epoch shows itself in pid 1, only systemd does as far as 
I know, that's a surefire test so it's good to have that data. You wouldn't by 
any chance know about runit would you, I could get no data on that one either.

Original comment by [email protected] on 14 Jan 2015 at 7:58

• Changed state: Accepted

[GoogleCodeExporter]

For epoch, can you show this:

cat /proc/1/comm

That's the actual test done.

Original comment by [email protected] on 14 Jan 2015 at 8:03

[GoogleCodeExporter]

Thx for the quick response. I could ask about runit from someone I know.

http://www.troubleshooters.com/linux/init/manjaro_experiments.htm#12232014_pure_
runit_init_proof_of_concept

Original comment by [email protected] on 14 Jan 2015 at 8:04

[GoogleCodeExporter]

Here's the epoch output:

$ cat /proc/1/comm
epoch

Original comment by [email protected] on 14 Jan 2015 at 8:06

[GoogleCodeExporter]

The initial runit/epoch tests both suffered from the weakness of simply 
detecting if the executable exists, which is a bad init test, so if that can be 
fixed that's good. The runit test still depends on just seeing if some files 
exist on the system, as does epoch, which is what led to the false detection.

Original comment by [email protected] on 14 Jan 2015 at 8:07

[GoogleCodeExporter]

Yup, I thought so too.

Epoch creates symlinks to itself for init, halt, shutdown, etc, much like 
systemd-sysvcompat does for systemd/systemctl.

With runit it could work though, as I think runit can run work both as pid 1 
and as some other pid.
http://www.smarden.org/runit/runit-init.8.html

Original comment by [email protected] on 14 Jan 2015 at 8:16

[GoogleCodeExporter]

This issue should be resolved in 2.2.17

If similar issues appear for runit post another issue report and it will get 
fixed as well.

Any init system that shows in PID 1 is preferred, though because in theory 
some, I think runit for example, may also be intended to work in bsds, that 
would require a different test than /proc/1/comm 

thanks for the bug report.

Original comment by [email protected] on 14 Jan 2015 at 8:44

• Changed state: Done

[GoogleCodeExporter]

Thanks for the bug fix :)

Original comment by [email protected] on 14 Jan 2015 at 8:54

[GoogleCodeExporter]

Hi,

My friend replied that when the system was booted using runit (by putting 
init=/usr/bin/runit-init into the kernel line of Grub), the output was:

runit

Original comment by [email protected] on 15 Jan 2015 at 5:59

[GoogleCodeExporter]

Hi, a follow up to this issue.

Now inxi shows the correct init and rc when using openrc, but it is showing the 
init's (sysvinit) runlevel rather than openrc's runlevel.

 Init: SysVinit rc: OpenRC runlevel: 3 

This is more of a feature request than a bug report, but if openrc was detected 
to be running, maybe the following command could be used to detect openrc 
runlevel:

$ rc-status -r
default

Here the runlevel is default.

Original comment by [email protected] on 24 Jan 2015 at 10:21

[GoogleCodeExporter]

Instead of using the `rc-status -r` command, the output of `cat 
/var/run/openrc/softlevel` could also be used (I got this info from the #openrc 
irc channel)

$ cat /var/run/openrc/softlevel
default$

(no newline after the runlevel)

Original comment by [email protected] on 24 Jan 2015 at 10:33

[GoogleCodeExporter]

Most of this issue is now corrected in 2.2.18, note that I have added rc-status 
debugging data to the inxi debugging data collector so it would be useful if 
someone could run, with inxi 2.2.18 this: inxi -xx@14

So I could see the output of rc-status -a / rc-status -l 
as well. When the system is running openrc that is of course.

I just used all the tests, cascading, from 
cat /run/openrc/softlevel
cat /var/run/openrc/softlevel
rc-status -r

Note further that I don't have default init level for openrc detected or tested 
here so it will still use the system default if detected for sysvinit but it 
will now show the value for example 'default' though that won't tell much if we 
don't know what default is.

Original comment by [email protected] on 24 Jan 2015 at 6:57

[GoogleCodeExporter]

First of all thanks for the fix :)
It seems to work:

Init: SysVinit rc: OpenRC runlevel: default 

I ran the command and it seemed to collect a lot of data and uploaded it 
automatically o.O

File: inxi-manjaro-20150125-003135-all.tar.gz

Original comment by [email protected] on 24 Jan 2015 at 7:07

[GoogleCodeExporter]

Great thanks for the data, now I can actually see what rc data is available.

This was a surprising set of data, heh, I didn't know sysctl could even run on 
a GNU/Linux system for example. 

Is inxi correct now, that you're running sysvinit with openrc? I see from the 
rc data that there's no other information available so that part looks right, 
though it's using the inittab to get the default still.

These datasets are enormously helpful to to get either existing or new inxi 
features because people's systems are so widely varying seeing what data is 
available for inxi to use is always valuable, this particular system is 
interesting so thanks.

If someone wants to confirm that runit is also now running and showing 
correctly let me know, I switched the ID method to use the proc test, though 
that involves losing bsd support if any bsds use runit, so if in the future 
there's an issue with bsd with runit not being right that will be dealt with 
when the needed data appears for that systems.

Thanks for the excellent issue and bug data, I wish all bug reporters were so 
helpful and complete, though another one I just got was also excellent, number 
66. Good bug report(ers) make this process so easy.

Original comment by [email protected] on 25 Jan 2015 at 6:36

[GoogleCodeExporter]

Hmmpf, I dont mind helping out but you might have mentioned that running `inxi 
-xx@14` would collect a lot of my data (some of which could be private, like 
passwords in /etc/fstab) and upload it automatically; that pissed me off. I 
blame myself partially for not checking the command for what it did before 
executing it.

Original comment by [email protected] on 25 Jan 2015 at 6:57

[GoogleCodeExporter]

I would never have thought passwords would be in /etc/fstab to be honest, 
though I can see now that I think of it a situation where it would be used, 
though it's something I would not expect very many people even know they can 
do. In general none of the data inxi collects is of any interest to anyone but 
me really, it's just hardware stuff/system stuff. I won't look at that file 
though.

Anyway, nobody sees this stuff except me and any other developer who I'd trust, 
so it's not a real issue, but thanks anyway, it's useful to see what real 
system data is, there's really no other way to debug hard problems, though this 
wasn't that hard.

Original comment by [email protected] on 25 Jan 2015 at 7:22

[GoogleCodeExporter]

To be complete, I checked that /etc/fstab file (because I was going to add in a 
filter rule to the data gatherer to remove that data if it contained passwords) 
and it contains no passwords. So there is no security issue here, I just wanted 
to make that clear to anyone who may get the wrong idea from the above 
statement. 

I would consider any actual security issue in inxi data gathering as a serious 
bug that should get fixed asap, which is what I was going to do here, but since 
there was no security issue, there is nothing to fix in this case, which is not 
surprising, since out of hundreds of datasets uploaded, none have contained any 
such sensitive information, but if anyone can show a clear realworld case where 
it's possible, and examples, inxi data gathering will be modified to exclude 
any data type that might contain such data. 

Also to be clear, these datasets are not uploaded to anyone other than me, or 
shared (unless to an inxi dev type), though technically they should be because 
many inxi features and functions cannot be tested or understood without seeing 
a very large set of data from differing systems and platforms, but it's not 
really practical to do that, nor is it right to do so, which means these 
datasets will remain private as a general rule. This is particularly relevant 
in cases where the actual system data is garbage (like dmidecode output, for 
ram in particular), or sensors, whose output is completely random  junk because 
manufacturers can basically call the items whatever they want, so you need to 
see a huge range of possible output forms to understand why some of the more 
complex inxi features have to be that way to be somewhat reliable.

However, thanks again for the most excellent issue/bug reporting, without such 
quality data and patches etc, inxi can't work long term in the ever fluid *nix 
environment.

Original comment by [email protected] on 26 Jan 2015 at 7:55