Feature request: fsh-like functionality

Norbert Nemec Norbert.Nemec.list at gmx.de
Fri Jul 23 21:05:15 EST 2010


On 23/07/10 10:33, Wout Mertens wrote:
> On Jul 23, 2010, at 11:14 , Norbert Nemec wrote:
>
>    
>> On 23/07/10 09:50, Norbert Nemec wrote:
>>      
>>> Hmm - based by these numbers I did some further test and am now suspecting that it is actually the login process of the bash that is eating up the time. Unfortunately, I cannot easily simplify the login scripts as a number of modules needs to be loaded. Furthermore, it is not quite clear to me which scripts are actually executed when calling 'ssh somehost "command"'. According to the documentation "command" is executed instead of a login shell. Still, the .bashrc seems to be read.
>>>        
>> Update: The real problem are /etc/bash.bashrc and /etc/profile -- both files are very complex and take significant time to process. I have no influence on the setup of the system. SSH does not seem to offer any way to issue a command without calling either of these two files. Am I missing something?
>>      
> Try calling a command with a full path and without special shell characters, I think SSH will then execute that directly. Try tracing execs from sshd on the receiving end?
>    
I checked the OpenSSH sources. Turns out that in session.c the sshd 
daemon actually *always* uses the login shell to interpret the command.

Turns out that furthermore, the bash tries to be smart and get in the 
way: /etc/bash.bashrc and ~/.bashrc are usually read only for 
interactive shells, not for shells that simply execute a command via the 
'-c' option. However -- bash automatically detects when it is called by 
rshd or alike. In this special case, it reads .bashrc anyways, with no 
way of switching off this behavior.

In most cases, I guess that this makes sense, because the environment 
would otherwise not be initialized. In my case, unfortunately, it means 
that a ssh command will always read /etc/bash.bashrc and will always 
take close to a second for it.

Unfortunately, this behavior is defined by sshd which I, as a user, have 
no control over. Guess, FSH remains the best workaround after all...



More information about the openssh-unix-dev mailing list