Repository navigation
Ctrl+z (suspend) does not work after zplug loaded #322
Description
Problem Summary
Ctrl+z (suspend) does not work after zplug loaded.
System Information
uname -a
Linux chajka 3.10.0-514.2.2.el7.x86_64 #1 SMP Tue Dec 6 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
- zsh version
zsh 5.0.2 (x86_64-redhat-linux-gnu)
- zplug version/commit
2.3.4
Minimal zshrc
source ~/.zplug/init.zsh
zplug load --verbose
If I comment out zplug load, Ctrl+Z becomes working well.
Steps to Reproduce
- Start zsh.
- Launch vim.
- Try to press Ctrl+Z to suspend vim, but it does not suspend. This also happen in emacs.
Activity
paulhybryant commentedon Dec 22, 2016
I ran into this a couple of times as well.
However, if I exit and start a new shell, it will work again. I cannot seem to reproduce it consistently.
kota65535 commentedon Dec 22, 2016
Hmm, in my environment, it continues to happen even if I restarted zsh...
paulhybryant commentedon Dec 22, 2016
Yeah in that case that is more troublesome.
babarot commentedon Dec 22, 2016
Perhaps you have set the
monitoroptionpaulhybryant commentedon Dec 22, 2016
Can you elaborate why using the monitor option will cause C-z to stop working?
From the zsh documentation of the monitor option I didn't find relevant information.
babarot commentedon Dec 22, 2016
Because it is an option related to on/off of job control.
paulhybryant commentedon Dec 22, 2016
Then if c-z stop working, it should be that the monitor option is not set (in your comment above you seem to indicate it stops working because monitor is set)
Thanks for the quick reply.
kota65535 commentedon Dec 22, 2016
Appending
set -o monitorto my .zshrc makes it work fine, thank you.paulhybryant commentedon Dec 22, 2016
I found that this is unset in base/core/load.zsh
There is a todo to make it the default.
bluekeyes commentedon Dec 24, 2016
I suggest this be reopened and considered a bug, as it seems wrong to me that calling
zplug loadchanges options outside of the loaded plugins. If intentional, it would be helpful to document this behavior; I'm in the process of switching to zplug and it took me quite a bit of time to track down why job control was disabled, since the ZSH docs say thatmonitoris on by default in interactive shells.paulhybryant commentedon Dec 28, 2016
What is the downside / concern of turning monitor on by default?
babarot commentedon Dec 28, 2016
@paulhybryant zplug performs many processing in the background process. Therefore, it is essential to turn off the monitor option.
11 remaining items
casimir commentedon Jan 9, 2017
This is still happening with version 2.4.1. And I have to say this is still painful. Any insight?
babarot commentedon Jan 9, 2017
Once all the background processes for zplug are done, the monitor option should be set automatically within 30 seconds.
https://github.com/zplug/zplug/blob/master/base/job/polling.zsh
casimir commentedon Jan 9, 2017
I can't reproduce it after a
zplug clear, guess that was some old cache causing this. Sorry for the noise. And thanks for the quick response @b4b4r07.RobertAudi commentedon Jan 23, 2017
@b4b4r07 I have had this issue for way way too long and could not solve it. But then I found a "loophole" which rendered virtually any potential fix useless:
The polling code only checks if the lock file exists. That means that if this file is added manually then zplug will disable the
monitoroption automatically and indefinitely.Also the
clearcommand doesn't remove the lock file. This means that it is not impossible that an old lock file that was not cleaned up (maybe due to a zplug job that might have been interrupted).I fixed the problem by manually removing the lock file. After that, everything worked normally out of the box (without the
set -o monitorfix or anything similar).I haven't looked around but a first step to resolve this issue once and for all would be to check the validity of the lock file. Or check if there are any zplug jobs still running. And if the lock file contains a pid, check if that pid exist and points to a zplug job. But I'm pretty sure testing for the existence of the file is not enough.
simonm commentedon Aug 1, 2018
Removing the lock file $_zplug_lock fixes the issue for subsequent restarts of zsh.
darthbanana13 commentedon Dec 11, 2018
I am still having this issue and
setopt monitorafter zplug load does not fix it. I can reproduce it consistently on all my machines.Here is my .zshrc
I tried zplug clear, removing the lock file but still noting. I have to manually type in the terminal
setopt monitor.Edit:
Removing job.lock worked.
drasill commentedon Feb 1, 2019
Removing the lock file did work for me.
antekone commentedon Apr 14, 2019
Removing the lock file works. The filename is
~/.zplug/log/job.lock.masto commentedon Jan 7, 2023
FWIW, I just ran into this issue on two different machines after using zplug for a couple of days. It seems like there is no stale lock detection, so it's easy to for something to be interrupted or fail and leave the lock file behind. And unless I'm missing something, there's no protection from multiple processes stomping on each other.
It's easy to fix, after you spend time trying to debug it, give up, and go on a web search that eventually leads to this bug.
I wonder if initializing _zplug_lock with a unique name (include pid?) would mitigate this.
docs(notes): add `wezterm` trouble shooting
garyo commentedon Jun 29, 2024
Just chiming in -- ended up here after a long search starting with "no job control in this shell" in my MacOS Terminal. Finally remembered I installed zplug a few weeks ago. Removing the lock file fixed it for me. What is the lock file for? Can I
rm -f ~/.zplug/log/job.lockin my init file to prevent this in the future?docs(notes): add `wezterm` trouble shooting
docs(notes): add `wezterm` trouble shooting
kirkegaard commentedon Dec 4, 2024
I ended up in this same situation and i did not have a
job.lockfile. Turns out that i for some reason installed zplug using brew but also via the install script. Removing one of them fixed it for me