gitstatus failed to initialize. Can't open file /tmp/*

[s0updev]

Version

Microsoft Windows [Version 10.0.19044.1706]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.16.3

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

1. Install Ubuntu with WSL2
2. Install oh-my-zsh and powerlevel10k in Ubuntu
3. Terminate WSL with wsl -t Ubuntu
4. Run Ubuntu

Expected Behavior

No errors on load

Actual Behavior

Getting an error:

[ERROR]: gitstatus failed to initialize.


  Zsh log (/tmp/gitstatus.POWERLEVEL9K.1000.4.1653403319.1.xtrace.log):

    +(anon):7> setopt monitor
    +(anon):9> ((  ! _GITSTATUS_STATE_POWERLEVEL9K  ))
    +(anon):51> ((  ! async  ))
    +(anon):52> ((  _GITSTATUS_CLIENT_PID_POWERLEVEL9K == sysparams[pid]  ))
    +(anon):54> local pgid
    +(anon):55> ((  0 < 20  ))
    +(anon):56> [[ -t 20 ]]
    +(anon):57> sysread -s 20 -t 5.0000000000 -i 20 'pgid[$#pgid+1]'
    +(anon):55> ((  20 < 20  ))
    +(anon):59> [[ '                  90' == \ #<1-> ]]
    +(anon):60> typeset -gi 'GITSTATUS_DAEMON_PID_POWERLEVEL9K=pgid'
    +(anon):62> sysopen -w -o cloexec -u req_fd -- /tmp/gitstatus.POWERLEVEL9K.1000.4.1653403319.1.fifo
    (anon):sysopen:62: can't open file /tmp/gitstatus.POWERLEVEL9K.1000.4.1653403319.1.fifo: no such file or directory
    +(anon):62> return

  System information:

    zsh:      5.8
    uname -a: Linux LAPTOP-IRKGT53C 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Diagnostic Logs

WslLogs-2022-05-24_20-41-47.zip

As the gitstatus creator states:

WSL2 on Win11 starts shell while the OS is booting up. This leads to weird things such as /tmp missing.
romkatv/gitstatus#234 (comment)

This happens only on load of Ubuntu, if I open it again there's no error:

So you need to terminate the Ubuntu WSL and open it again to get this error

[elsaco]

Some of the comments in romkatv/gitstatus#234 might be correct, but if you look at zsh trace it's written in /tmp directory (/tmp/gitstatus.POWERLEVEL9K.1000.4.1653403319.1.xtrace.log). If you're so far into shell initialization and gitstatusd fails it's not for lack of access to /tmp directory.

If you source powerlevel10k.zsh-theme on the last line in your .zshrc does it still fails?

[s0updev]

like this?

still fails yes

[romkatv]

Can you reproduce it with ~/.zshrc as follows?

source ~/gitstatus/gitstatus.plugin.zsh
gitstatus_start MY

You'll need to run this command once beforehand:

git -C ~ clone --depth=1 https://github.com/romkatv/gitstatus.git && ~/gitstatus/install -f

[s0updev]

Yes, got the same error

[s0updev]

Can you reproduce it with ~/.zshrc as follows?

source ~/gitstatus/gitstatus.plugin.zsh
gitstatus_start MY

Or do you mean only with these two lines in .zshrc?

[romkatv]

Can you reproduce it with ~/.zshrc as follows?

source ~/gitstatus/gitstatus.plugin.zsh
gitstatus_start MY

Or do you mean only with these two lines in .zshrc?

Yes, that's what I meant. This is the whole ~/.zshrc, nothing else should be in it. In addition, ensure that you don't have any other zsh rc files by running the following command:

rm -f -- ~/.zshrc.zwc ~/{.zshenv,.zprofile,.zlogin,.zlogout}{,.zwc}

[s0updev]

The error and the theme is gone with that .zshrc

[romkatv]

It's expected that the theme is gone. We just want to trigger the error.

Please try this ~/.zshrc:

source ~/gitstatus/gitstatus.plugin.zsh
gitstatus_start -a MY
sleep 1.0
gitstatus_start MY

If this doesn't produce the error, try replacing 0.5 with 0.0, 0.1, 0.5, 1.0 and 2.0.

My current theory is that all files under /tmp get deleted soon after WSL boots up. This explains the error and also why the xtrace file is missing the first half. To clarify, gitstatus_start -a MY creates /tmp/gitstatus.*.fifo and gitstatus_start MY tries to open it. We have a sleep in between to wait for whatever process is responsible for deleting our files.

[s0updev]

With first try, sleep 1.0

0.1 Doesn't trigger the error, 0.5 does

[romkatv]

Let's try this ~/.zshrc:

>/tmp/foo <<<''
sleep 1.0
[[ -e /tmp/foo ]] || print -ru2 error

Once again, try different values instead of 1.0 if that one doesn't print "error".

[s0updev]

The same result

I narrowed it down a bit, 0.1 doesn't trigger, 0.2 does

[romkatv]

@s0updev Thanks for your help debugging this.

At this point the test case is simple and has no dependencies on my code. I'm bowing out 😄

[s0updev]

@romkatv You're welcome 🙂

[weebao]

@romkatv Has this been resolved? Or we just accept that it is a bug in the OS and there's no way to go around it?

[romkatv]

I don't know whether the bug in the OS has been fixed or not. You could try to figure this out by clicking on linked issues and digging through them. This one looks fruitful: #11739

I haven't implemented any workarounds for this bug in powerlevel10k. Even if I did, all other software you might be running can easily be affected by this bug. I personally would not use an OS with a bug as severe as this.