`w`: Shows incorrect value in the `WHAT` column

[alxndrv]

There is a discrepancy in the information output by this implementation of w and the reference implementation:

$ cargo run -q w  
 21:22:38 up  1:06,  1 user,  load average: 0.09, 0.27, 0.58
USER     TTY       LOGIN@   IDLE   JCPU   PCPU  WHAT
alx      tty1      20:16    1:06m  0.00   0     /bin/sh/usr/bin/niri-session-l

$ w
 21:22:38 up  1:06,  1 user,  load average: 0.09, 0.26, 0.58
USER     TTY       LOGIN@   IDLE   JCPU   PCPU  WHAT
alx      tty1      20:16    1:06m  0.00s   ?    systemctl --user --wait start niri.service

1. The value of WHAT seems to be stripping away all whitespace from the command it's trying to display.
   /bin/sh/usr/bin/niri-session-l is clearly supposed to be this shell script invocation: /bin/sh /usr/bin/niri-session -l

2. The actual content of the column refers to two slightly different steps in the invocation chain.
   In this specific case /usr/bin/niri-session is a bash script which is invoked by the display manager at login-time.
   systemctl --user --wait start niri.service is something that is called from inside this bash script.

Looking at these processes with ps, I can confirm that both are still running, and the /bin/sh invocation is indeed higher up in the invocation chain (it has a lower PID).
Seeing how there's two different processes being shown in the WHAT, I'd also assume that the PCPU values would also have a discrepancy if they anything else than zero 🙂

[alxndrv]

The whitespace issue seems to stem directly from how the kernel exposes the value in /proc/<pid>/cmdline:

$ cat /proc/1161/cmdline 
/bin/sh/usr/bin/niri-session-l% 

$ xxd /proc/1161/cmdline
00000000: 2f62 696e 2f73 6800 2f75 7372 2f62 696e  /bin/sh./usr/bin
00000010: 2f6e 6972 692d 7365 7373 696f 6e00 2d6c  /niri-session.-l
00000020: 00                                       .

Simply reading it as a string makes the whitespace disappear but the binary shows that there's actually a NULL byte in place of every whitespace which can be parsed.

[alxndrv]

The session process being wrong seems to share the root cause with #183. Both are seemingly caused by the fact that the uutils implementation has no systemd awareness, where as procps-ng includes explicit checks for various init systems.

As for the whitespace issue, opened a PR for it: #666.
Feel free to close this one if you feel that it's not sufficiently different from #183.

[Krysztal112233]

@Bluemangoo I recall you previously introduced systemd awareness?

[Bluemangoo]

I only introduced systemd in top:

procps/src/uu/top/src/platform/linux.rs

Lines 19 to 64 in 75e5833

	pub fn get_nusers_systemd() -> uucore::error::UResult<usize> {
	use std::ffi::CStr;
	use std::ptr;
	use uucore::error::USimpleError;
	use uucore::libc::*;
	// SAFETY: sd_booted to check if system is booted with systemd.
	unsafe {
	// systemd
	if sd_booted() > 0 {
	let mut sessions_list: *mut *mut c_char = ptr::null_mut();
	let mut num_user = 0;
	let sessions = sd_get_sessions(&mut sessions_list);
	if sessions > 0 {
	for i in 0..sessions {
	let mut class: *mut c_char = ptr::null_mut();
	if sd_session_get_class(
	*sessions_list.add(i as usize) as *const c_char,
	&mut class,
	) < 0
	{
	continue;
	}
	if CStr::from_ptr(class).to_str().unwrap().starts_with("user") {
	num_user += 1;
	}
	free(class as *mut c_void);
	}
	}
	for i in 0..sessions {
	free(*sessions_list.add(i as usize) as *mut c_void);
	}
	free(sessions_list as *mut c_void);
	return Ok(num_user);
	}
	}
	Err(USimpleError::new(
	1,
	"could not retrieve number of logged users",
	))
	}

[Bluemangoo]

If anyone would pick up this issue, please pay attention that as a MIT licensed project we cannot use GPL dependents. Most libsystemd wrapper crates are not licence capable.