justjanne / powerline-go

A beautiful and useful low-latency prompt for your shell, written in go

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

user.Current() can take up to 5 seconds to complete

ctryti opened this issue · comments

Describe the bug
user.Current() sometimes takes up to 5 seconds to complete, causing the execution of powerline-go in _update_ps1() to sometimes hang the terminal (for around 5 seconds) between commands.

We've narrowed it down to this call: https://github.com/justjanne/powerline-go/blob/main/powerline.go#L62

To Reproduce
Steps to reproduce the behavior:
(We're not sure if this happens only in our environment)
Run time -v powerline-go in a while-loop and grep all 'wall clock' times that took longer than 0:00.010. Eventually, some executions will take more than 100 milliseconds to complete and be printed to console. Example:

$ while true; do { \time -v $GOPATH/bin/powerline-go; } 2>&1 | grep "Elapsed (wall clock) time (h:mm:ss or m:ss):" | grep -v "0:00.0"; done
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:05.00

Expected behavior
We expect powerline-go to never hand the terminal for up to 5 seconds

Environment (please complete the following information):

  • OS: linux
  • Architecture: 5.11.0-43-generic #47~20.04.2-Ubuntu SMP Mon Dec 13 11:06:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
  • Shell: bash

Additional context
This seems to be a problem in the Go standard library or our environment (Citrix Linux VDA), not in powerline-go itself. A workaround we use here is to just create userInfo manually like this:

	// userInfo, err := user.Current()
	// if userInfo != nil && err == nil {
	// 	p.userInfo = *userInfo
	// }
	p.userInfo = user.User{Username: os.Getenv("USER"), HomeDir: os.Getenv("HOME")}

We're not sure if this is the proper way to avoid using user.Current() in order to be cross-plattform compatible. But at least this works on our end on linux-environments.

Turns out this is a problem with our environment. Any code that tries to show user-information (like ls -l) has the same intermittent problem. We suspect its something to do with the desktops being joined to Active Directory incorrectly.