Hi,

I am using inxi on Manjaro Linux, with OpenRC on top of sysvinit, while inxi shows init as Epoch, and rc as OpenRC.

Output can be found here: http://paste2.org/z93aFUUJ

For checking sysvinit maybe you guys could check if pid 1 is named init, because when I use Epoch pid 1 is named as epoch.

When using OpenRC with sysvinit:

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

When using Epoch:

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

Also OpenRC and runlevel are squashed together in the output, ie:

rc: OpenRCrunlevel

Regards, Aaditya

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

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

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.

For epoch, can you show this:

cat /proc/1/comm

That's the actual test done.

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

Here's the epoch output:

$ cat /proc/1/comm epoch

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.

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

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.

Thanks for the bug fix :)

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

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.

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)

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.

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

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.

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.

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.

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.