Re: Pause when quitting under FreeBSD

Re: Pause when quitting under FreeBSD

[Dan Nelson]

In the last episode (Jul 27), Mark Daniel Reidel said:
> I'm not 100% sure if this is the right place to post this problem,
> but ever since I switched to a 64bit OS and installed my shell of
> choice, quitting zsh suddenly takes about 2 or 3 seconds. Since my
> configuration comes from an NFS-server, I can be 100% sure that it's
> the same unter FreeBSD 5.4 and 6 (which is the one that seems to have
> problems). I already tried a ktrace to maybe find the bugger, but the
> time-consumption seems to be during some breaks. Here's the important
> parts:
> 
> [...]
>    744 zsh      Events dropped.
>    744 zsh      1122421279.260961 RET   open 3
>    744 zsh      Events dropped.
>    744 zsh      1122421279.271187 RET   close 0
>    744 zsh      1122421280.524404 CALL  break(0x876c20)
>    744 zsh      1122421280.524420 RET   break 0
>    744 zsh      1122421280.563815 CALL  break(0x871c20)
> [...]
>    744 zsh      1122421281.009755 CALL  break(0x835c20)

If you can switch to another shell quickly and kill -STOP it, you
should be able to attach a gdb session and get a stack trace.  Or, run
gcore on it (which will SIGSTOP it temporarily) and gdb the resulting
corefile.  Since the next thing zsh does is unlink the history
lockfile, I'd guess the problem is hist.c:hend() or savehistfile()
somewhere.  Take a look at your ~/.zsh_history file; do you maybe have
some really really long lines in it?  Maybe an NFS glitch caused a run
of NULLs to get stored in there.

>    744 zsh      1122421281.009771 RET   break 0
>    744 zsh      1122421281.548473 CALL  break(0x7d4c20)
>    744 zsh      1122421281.548534 RET   break 0
>    744 zsh      1122421281.548602 CALL  unlink(0x7b6960)
>    744 zsh      1122421281.548606 NAMI  "/home/mark/.zsh_history.LOCK"
>    744 zsh      1122421281.553918 RET   unlink 0
> [...]

-- 
	Dan Nelson
	dnelson@allantgroup.com

Pause when quitting under FreeBSD

[Mark Daniel Reidel]

Hi there!

I'm not 100% sure if this is the right place to post this problem, but
ever since I switched to a 64bit OS and installed my shell of choice,
quitting zsh suddenly takes about 2 or 3 seconds.
Since my configuration comes from an NFS-server, I can be 100% sure that
it's the same unter FreeBSD 5.4 and 6 (which is the one that seems to
have problems).
I already tried a ktrace to maybe find the bugger, but the
time-consumption seems to be during some breaks. Here's the important parts:

[...]
   744 zsh      Events dropped.
   744 zsh      1122421279.260961 RET   open 3
   744 zsh      Events dropped.
   744 zsh      1122421279.271187 RET   close 0
   744 zsh      1122421280.524404 CALL  break(0x876c20)
   744 zsh      1122421280.524420 RET   break 0
   744 zsh      1122421280.563815 CALL  break(0x871c20)
[...]
   744 zsh      1122421281.009755 CALL  break(0x835c20)
   744 zsh      1122421281.009771 RET   break 0
   744 zsh      1122421281.548473 CALL  break(0x7d4c20)
   744 zsh      1122421281.548534 RET   break 0
   744 zsh      1122421281.548602 CALL  unlink(0x7b6960)
   744 zsh      1122421281.548606 NAMI  "/home/mark/.zsh_history.LOCK"
   744 zsh      1122421281.553918 RET   unlink 0
[...]

As you can see, it takes about 2.3s doing breaks and this is *really*
annoying if you fire up some terminals and want to close them wich
ctrl+d, because the terminal just sits there and twiddles thumbs :-/

Is there anything I could maybe do to help get rid of this? I already
tried not to do a setopt APPEND_HISTORY or SHARE_HISTORY, but it seems
to be totally unrelated. Also NFS doesn't seem to be the bugger, because
the problem exists for root, too and /root is of course not on an NFS-mount.

Hope anyone can help me or at least provide some debugging hints

	- Mark
-- 
Fortune cookie of the hour:
Be free and open and breezy!  Enjoy!  Things won't get any better so
get used to it.

Re: Pause when quitting under FreeBSD

[Mark Daniel Reidel]

Dan Nelson wrote:

> corefile.  Since the next thing zsh does is unlink the history
> lockfile, I'd guess the problem is hist.c:hend() or savehistfile()
> somewhere.  Take a look at your ~/.zsh_history file; do you maybe have
> some really really long lines in it?  Maybe an NFS glitch caused a run
> of NULLs to get stored in there.

That seems to have been it. There were some NULLs inside every user's
history-file. After removing it, everyting works smooth again. Now I
only have to find out how those NULLs came in there, but that's not
zsh-matter ;o)
Thanks for the quick hint!

-- 
Fortune cookie of the hour:
Be free and open and breezy!  Enjoy!  Things won't get any better so
get used to it.