Inxi testing

[Member h2]

Helpful

Up

0

::

runit should be working, isn’t it? It belongs to proc 1, I don’t know any alternate way of finding it. But inxi has supported runit for a long time. My lack of love for systemd over the years made me always go out of my way to support all non systemd init systems.

inxi system information script (install info) :: inxi git

[Member h2]

Helpful

Up

0

::

Just post: cat /proc/1/comm
on the runit system, it should show ‘runit’ or something like that, paste in EXACTLY what the output is.

The only failure could come from if it were upper case for some reason, which those aren’t supposed to be. But I didn’t do a to lower case on it.

There’s 3 components that activate:

-Ix – init system detection, run
-Ixx – init system version, if available, runlevel/target + default if found
-Ia – init tool, like systemctl, rcctl, and so on. runit should be supported unless it stopped using sv

inxi system information script (install info) :: inxi git

[Moderator caprea]

Helpful

Up

0

::

h2 wrote:

it’s not under System -S/–system, it’s under -I/–info

Yes and works, no version though.

$ inxi -Ixx
Info:
  Processes: 176 Uptime: 28m Memory: 2.79 GiB used: 1.26 GiB (45.3%)
  Init: runit v: N/A runlevel: 2 Compilers: gcc: 10.2.1 alt: 10 Packages:
  apt: 1216 Shell: Bash v: 5.1.4 running-in: roxterm inxi: 3.3.19

$ cat /proc/1/comm
runit

[Member h2]

Helpful

Up

0

::

Yes, there wasn’t a huge area for that one to fail in. I checked the runit man page, no –version/-v etc. It has no options at all. With -Ia it should show tool: sv as well. Good to see the runlevel works with runit, I wasn’t sure if that would work.

inxi system information script (install info) :: inxi git

[Forum Admin anticapitalista]

Helpful

Up

0

::

I was looking in the wrong place. runit does show up

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member h2]

Helpful

Up

0

::

Yes, I reaiized that when you mentioned ‘System’. In case anyone is wondering, while there is a rough logic to how information is distributed between -S and -I, the actual story is more along these lines:

From the start of inxi, there were a set of things that were generally most important to see for support people, that’s -S/–system, the kernel version, plus related kernel stuff, distro + version, wm/desktop/dm and related. Over time related things were added, like kernel parameters, toolkit, and so on. These were generally things that caused the most issues for users on the software level of the stack, or which were most important to know right off before reading anything else, like that it’s an obsolete distro release or whatever.

So –system actually means: the data that is most likely to be relevant to the support person or end user.

There was a second set of things considered either to not fit with that set, like core hardware stuff, ram use, or os stuff, like processes, uptime, init, and then info about what inxi is running in, the sehll etc, but this set was more about those being less important to see on top line first thing. That’s -I/–info . Over time more stuff of secondary importance was added there, like running in, package info, wakeups, installed compilers.

So –info actually means, everything else that doesn’t fit into the normal lines output by -b, -F, -v 1 and greater.

The two lines, -S and -I, are unique in inxi, because neither generates data from one source, they are a collection of various tools that create each set of output, so what is required to generate that output is far more than most people would suspect. Just desktop/wm and distro id require about 1300 lines of code, and updates to add new stuff, or failed old ids, for example.

To avoid repetition, and to put data where it logically belongs when non default switches like -t, -m, -r, are used, two of the -I data types move depending on what other options are used, for example, ram report moves to -m if that flag is used, or to -t or -tm [processes with memory] if that is used, and packages moves to -r / –repos if that flag is used.

Now you know.

• This reply was modified 10 months, 3 weeks ago by h2.
• This reply was modified 10 months, 3 weeks ago by h2.
• This reply was modified 10 months, 3 weeks ago by h2.

inxi system information script (install info) :: inxi git

[Forum Admin anticapitalista]

Helpful

Up

0

::

While you’re here, @h2, what does tool: service mean?

Info:
  Processes: 163 Uptime: 7h 30m wakeups: 3 Init: runit v: N/A runlevel: 2
  tool: service Compilers: gcc: 10.2.1 alt: 10 clang: 11.0.1-2 Shell: Bash
  v: 5.1.4 running-in: urxvt inxi: 3.3.19

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member h2]

Helpful

Up

0

::

I forgot to mention, to see what belongs to what, use -Iay1

Info:
  Processes: 676
  Uptime: 109d 22h 37m
    wakeups: 1401
  Memory: 31.34 GiB
    used: 22.44 GiB (71.6%)

  Init: systemd
    v: 250
    target: graphical (5)
      default: graphical
    tool: systemctl
...

tool is the tool you use to interact with the init system, could be /etc/init.d (sysvinit if it doesn’t have service), systemctl (systemd), service (various linux, and some bsds), sv (runit), rcctl (openbsd I think), etc.

It’s a sequence of tests, from most specific (rcctl, systemctl), to least likely, to fallbacks. For example, in your case, I don’t know if you are using runit’s sv or just service, but service test comes before sv test, which probably isn’t right, not sure.

When you start/stop a service, what command do you use with runit?

I suspect the sv test should come before the service test. But service should not be installed if sv is, since you should have only one init service control tool or method. init.d direct is the last fallback, since service could for example have tripped init.d commands, same for rc.d, those are both direct init file locations.

Of course, service could be mapped to sv, like it used to be mapped to /etc/init.d/*, and is I think still mapped to /etc/rc.d/* on some bsds. I think that’s why it comes before sv test, since it’s more likely service cmd is being used to interact with init system if it’s installed, via mappings, than it is that sv is being used directly. That may have been my logic, or it may have just been alphabetical sort order.

• This reply was modified 10 months, 3 weeks ago by h2.
• This reply was modified 10 months, 3 weeks ago by h2.
• This reply was modified 10 months, 3 weeks ago by h2.

inxi system information script (install info) :: inxi git

[Author]

Posts