/init does not create /var/run/utmp

[christoh]

An empty (0 bytes) /var/run/utmp file should be created by /init

This would help with certain failures and/or warning messages of various programs (not only /bin/who).

My current workaround: Use 'touch /var/run/utmp' in some "system startup script".

[jackchammons]

Certain files that are laid down by init or updated by the system during runtime are not yet supported. We are evaluating which ones we will be adding in the future.

Just out of curiosity, of what use are the errors/warnings typically available in utmp?

[fehrin]

Today i got an error message during apt-get upgrade which referenced the utmp file, just for the records (the full error message is no longer available since i cloded the terminal in the meantime).

[therealkenc]

An empty (0 bytes) /var/run/utmp file should be created by /init

Not an empty one. One that establishes a runlevel, ref #1761. Goes spirituality to #2530 and #994 (depending on your disposition).

[therealkenc]

From #1761 (message), a runlevel can be established with something along the lines of:

sudo bash -c "echo '[1] [00049] [~~  ] [runlevel] [~           ] [4.4.0-17115-Micoroso] [0.0.0.0        ] [Wed Feb 28 13:27:14 2018 STD]' | utmpdump -r > /var/run/utmp"

The ask here is that WSL brand /init establish a runlevel. It is a high value low cost ask that would quash longstanding errors/warnings that manifest in both WSL 1 and WSL 2. A minimalist (by-design ) init doesn't have to do much, but setting up /var/run/utmp is kind of on the short-list of things init has to do. The OP issue was submitted when WSL was largely a no-daemon affair (great for git/gcc/sed/awk, but not necessarily sshd/nginx/mongod) but that hasn't been the case for a long time now.

[cbenard]

The OP issue was submitted when WSL was largely a no-daemon affair (great for git/gcc/sed/awk, but not necessarily sshd/nginx/mongod) but that hasn't been the case for a long time now.

I was actually hoping this issue was mooted by WSL2 with its more full Linux support. I'm sad to see the wsl2 label applied. This issue is incredibly old with a seemingly 1-line fix possible. Is there a reason it's not getting addressed?

[viliml]

Any progress? Is there a workaround available that would make commands like who, w, users etc. work?

[therealkenc]

It would take a little more effort to make that phancy.

[newcanopies]

sudo bash -c "echo '[1] [00049] [~~ ] [runlevel] [~ ] [4.4.0-17115-Micoroso] [0.0.0.0 ] [Wed Feb 28 13:27:14 2018 STD]' | utmpdump -r > /var/run/utmp"

running the above on 5.4.72-microsoft-standard-WSL2, returns: Utmp undump of /dev/stdin

runningexit closes that terminal bash tab, instead of logout.

underlying issue: w, who -H, who -u returns 0 users!

[therealkenc]

Try:

$ sudo bash -c "echo '[1] [00053] [~~  ] [runlevel] [~       ] [5.4.91-microsoft-standard-WSL2] [0.0.0.0    ] [2021-04-05T23:10:15,040218+00:00]' | utmpdump -r > /var/run/utmp" 2> /dev/null

Which sets up the runlevel, not the login user. You don't need it for who.

running exit closes that terminal bash tab, instead of logout.

That is by-design unless you start the terminal from a Windows shell.

All of which is for illustration to set up /var/run/utmp. No one would actually type these commands. It would take a little more effort to make that phancy.

[therealkenc]

and $ w still returns 0 users

That is because the sudo bash line cited (quoth) "sets up the runlevel, not the login user". The login(1) command sets up the user for the login session.

I am having a bunch of user-permission issues due to this.

It is unlikely that you are having a bunch of user-permission issues due to a zero-thumbs-up feature request from 2016. Possible, but unlikely.

[klugerama]

@therealkenc

Which sets up the runlevel, not the login user. You don't need it for who.

and

and $ w still returns 0 users

That is because the sudo bash line cited (quoth) "sets up the runlevel, not the login user". The login(1) command sets up the user for the login session.

Are you saying that this issue is not directly related to the problem of who not working? If so, why were all of the issues (#913, #2806, #6393) closed as duplicates of this one?

who still doesn't work after doing this; is the solution to that to set up login as part of the uh, login process (which doesn't appear to be happening)?

[samohtGTO]

we could run a startup script form a automation who runs the touch /var/run/utmp

[oldium]

Also who -m is unusable because of missing support for utmp/wtmp from WSL2 side.

[borjamunozf]

Could be this related to the fact that write or wall does not seem to work?

[samohtGTO]

you can use .bashrc to automaticly do the cmd