Closed lee-aaron closed 1 year ago
I just ran into the same issue. Same symptoms of the shell hanging for a good few seconds after a command finishes execution (and ps
shows atuin history end
running so this is likely the _atuin_pre_prompt
hook from the atuin init
). Interestingly enough this does not happen all the time but either every now and then or after a fixed count. Not quite sure which one of the two.
I suspect this is related to the fact that I recently imported a large zsh
history file with ~50k entries and use sync (with my own server, although it is in the local network). Manually running atuin sync
takes about the same time as the hanging prompt rendering (~7sec in my case).
Either way, this is pretty annoying and I would consider it pretty much a critical bug (a history augmentation plugin should not get in the way of shell execution but rather do its dirty work in the background â although this seems like a bug to me).
If there is anything I could try to get you more debug info, let me know!
This would be the automated periodic sync running. It's supposed to run in the background.
How have you configured your atuin shell installs? That would help narrow down the root cause
Hey Conrad,
I am not quite sure what details you are asking for so here is a general collection of setup details â let me know if you are looking for anything more specific.
nu
is configured as the startup shell with a manually injected $env.PATH
to make stuff work
(in case it matters, setup scripts in the repo at the bottom)Both nushell and atuin were installed with cargo install
.
Atuin was initialised by running atuin init nu --disable-up-arrow > ~/.local/share/atuin/init.nu
which is subsequently sourced in a file referenced by the one at $nu.config-path
.
If it helps I could change the _atuin_pre_prompt
hook so that it appends the output of atuin history end
to a file (and increase the log level to debug).
EDIT: I can confirm that changing the sync_frequency
config option to 0
does indeed cause the shell to hang after every command. However, setting RUST_LOG
to debug
and removing the | null
does not produce any additional output đĸ
let _atuin_pre_prompt = {||
let last_exit = $env.LAST_EXIT_CODE
if 'ATUIN_HISTORY_ID' not-in $env {
return
}
with-env { RUST_LOG: debug } {
echo "hello world"
atuin history end $'--exit=($last_exit)' -- $env.ATUIN_HISTORY_ID
}
}
After analysing it for a bit longer, it seems that it is not the actual atuin history end
call which hangs but rather a side-effect it causes. I have modified the pre-prompt hook to display time-stamps before and after said command which complete instantly:
with-env { RUST_LOG: error } {
echo post-start (date now | to text)
atuin history end $'--exit=($last_exit)' -- $env.ATUIN_HISTORY_ID | null
echo post-finsh (date now | to text)
}
However, after this block completes the shell still hangs for a couple of seconds before the prompt is rendered again. Based on the output from ps
and the fact that removing the atuin history end
"solves" this delay, I would assume that this is caused by a side-effect triggered by that command.
Digging deeper, it looks like the shell process tree consumes 100% CPU (presumably while running the side-effect of history end
) â may this be the culprit? If the background task caused by atuin and the prompt rendering run in the same process, then maybe that's what blocks the prompt? This would be consistent with other behaviour like CTRL+C
not working (although that may just be an intrinsic of nu
, haven't used it long enough to judge that).
https://github.com/atuinsh/atuin/assets/5037967/bf55f92b-9673-4f3f-9e4a-9ff1c5d5bcd2
Digging into the code, it seems that it is not actually RUST_LOG
which has to be set but ATUIN_LOG
(inconsistency with the shell init script?). Setting that immediately produces a metric ton of output which I have appended below. Unfortunately it has been mildly butchered by the shell for some reason âšī¸
Original atuin_log.txt
Cleaned (s/ +/ /g
)
atuin_log_clean.txt
This excludes the hyper
and h2
debug logs because my god do they take debug
liberally :D
(if you need them let me know)
Digging into the code, it seems that it is not actually RUST_LOG which has to be set but ATUIN_LOG
Yeah, I spotted that too #1263
Atuin was initialised by running
atuin init nu --disable-up-arrow > ~/.local/share/atuin/init.nu
which is subsequently sourced in a file referenced by the one at$nu.config-path
.
Ah yes, nu, I was looking at the shell init script earlier and it doesn't see we use background processing in nu on end. This means that it will pause while it syncs
Setting that immediately produces a metric ton of output which I have appended below
Ok from your logfile I have a bit more context into what's going on here. It looks like your client is attempting to do a full sync everytime. I see 48 rows returned: 1100
lines and a final rows returned: 278
, this adds up to reported we have 53078
rows.
I also see that you self host your sync server. Can you confirm what version that's running on?
Anyway, besides what is causing this issue here I think I'm going to set a 1s timeout on background sync. wdyt @ellie ?
Ah, I see, for bash the process is deferred as a background task! It seems that nu does not support that natively?
I can think of two possible solutions:
pueue
if available (although checking whether the daemon is actually running might be required to prevent accidental non-sync)P.S.: Is there any particular reason that the sync takes this long and consumes that much CPU?
Anyway, besides what is causing this issue here I think I'm going to set a 1s timeout on background sync. wdyt @ellie ?
I'd go for something more like 3-5s, bearing in mind some setups will have a higher network latency + there's a few calls going on. But it makes sense!
P.S.: Is there any particular reason that the sync takes this long and consumes that much CPU?
This is probably the issue here, and I'm unsure if it's an issue with the code or your current setup.
If you could confirm whether you're running a tagged release on the server, or a commit sha - and also if there are any error logs on the server. It's usually pretty descriptive if there's something going on that aborts sync.
One such example would be where you have a very large history item. The server is generally pretty defensive about this by default, you may wish to configure the size allowed there
đ I found this out a while ago and am playing around with it. However, I noticed some processes are hanging when I switched from zsh to fish.
I just opened a new terminal and typed
ls
before this. It's a bit annoying when I close the terminal tab but are there any solutions to this?