bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix hang if $OLDPWD points to inaccessible directory


From: Mikulas Patocka
Subject: Re: [PATCH] Fix hang if $OLDPWD points to inaccessible directory
Date: Sat, 30 Sep 2017 10:01:47 +0200 (CEST)
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)


On Fri, 29 Sep 2017, Eduardo A. Bustamante López wrote:

> On Fri, Sep 29, 2017 at 12:51:37AM -0700, L A Walsh wrote:
> [...]
> > Why does bash clear OLDPWD when a child script is started?
> > 
> > OLDPWD is exported and passed to any children, but bash apparently clears
> > OLDPWD whenever a child script is started...
> > 
> > GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
> > 
> > Can bash be fixed to preserve the value of any OLDPWD in its initial
> > environment, like it does with PWD?
> 
> Eh, 4.1? That's ~8 years old.
> 
> Check the commit I linked, there's the fix you're asking for.
> 
> > ---
> > 
> > I don't see a reason...
> > I see a "want", but no real reason....
> > 
> > I'd agree it's a rare event to hit though, but when you do...
> > 
> > Requires console access, but changing /etc/profile to
> > insert a bad OLDPWD to a known down network location might not be
> > considered a trivial occurrence to someone stressed out and trying to log
> > in and find out why everyone logging in is hanging...
> 
> Why would logins hang? We're talking about OLDPWD here. OLDPWD is not
> set if you're not logged in.
> 
> The reported scenario is:
> 
> - You are in a network filesystem (let's call it /net/myuser)
> - chdir() somewhere else, e.g. /home/myuser 
>   (OLDPWD=/net/myuser, PWD=/home/myuser)
> - Then you unplug your computer, or the computer that provides the
>   network share.
> - Then you start a new bash shell, which will hang because it'll try to
>   stat($OLDPWD).
> 
> To which the solution is: unmount the network share properly.

Unmounting it doesn't solve it. I unmount /ssh/host/, bash attempts to 
execute stat("/ssh/host/directory"), this is intercepted by automounter 
and the automounter tries to mount "/ssh/host" again. Automounter spawns 
sshfs, sshfs spawns ssh, ssh tries to connect to the host, it times out 
after a minute. After a minute, automounter reports an error, the stat() 
syscall fails and bash continues.

If this delay happened only occasionally, it would be acceptable. But, if 
I start a desktop environment from command line and the $OLDPWD variable 
is propagated to every process in the desktop environment, then every bash 
script executed in the desktop environment will wait for the automounter 
to time out.

If you argue that this is misconfiguration of automounter or sshfs, what 
should it do instead? Surely it can't fail immediatelly, it will try to 
connect until some timeout - and every bash instance will then wait for 
this timeout in the stat syscall.

Here they fixed a similar problem in zsh, because it was poking 
directories in its directory history. 
https://github.com/grml/grml-etc-core/issues/51

Mikulas


reply via email to

[Prev in Thread] Current Thread [Next in Thread]