sshfs-static did not act on sigterm

[GoogleCodeExporter]

I have Mac OS starting and stopping in verbose mode. 

During the shutdown phase of a Mac OS restart, I *glimpsed* one line something 
like 

> sshfs-static ... did not act on sigterm

and shutdown took longer than usual to complete. 

###

I saw this line appear twice, on one other occasion, 
<http://code.google.com/p/macfusion/issues/detail?id=8>

Following the second occurrence I have an idea of the circumstances in which 
the issue *might* 
occur, I'll try to reproduce...

Original issue reported on code.google.com by grahampe...@gmail.com on 1 May 2007 at 1:34

[GoogleCodeExporter]

sshfs-static [pidnumber]: didn't act on sigterm

-- can occur when a mount point is not specified. For example: 

Last login: Mon Apr 30 21:56:32 on console
Welcome to Darwin!
grahamperrin:~ gjp22$ sshfs gjp22@omnium.freeman-centre.ac.uk:
sshfs: cannot find sshnodelay.so
warning: ssh nodelay workaround disabled
Password:
kextload: /Library/Extensions/fusefs.kext loaded successfully
grahamperrin:~ gjp22$ 

Original comment by grahampe...@gmail.com on 1 May 2007 at 1:51

[GoogleCodeExporter]

In greater detail: 

### Terminal window 1

Last login: Tue May  1 02:40:57 on ttyp1
grahamperrin:~ gjp22$ sshfs gjp22@omnium.freeman-centre.ac.uk: -o debug -o 
sshfs_debug
sshfs: cannot find sshnodelay.so
warning: ssh nodelay workaround disabled
Password:
Server version: 3
kextload: /Library/Extensions/fusefs.kext loaded successfully
^CKilled by signal 2.
umount: unmount(/): Operation not permitted
^Cumount: unmount(/): Operation not permitted
^Cumount: unmount(/): Operation not permitted
^Cumount: unmount(/): Operation not permitted
umount: unmount(/): Operation not permitted
umount: unmount(/): Operation not permitted
Killed
grahamperrin:~ gjp22$ 

^^^ control-c (four attempts) could not kill the process ^^^

### Terminal window 2 (read this alongside #1)

Processes:  71 total, 2 running, 69 sleeping... 225 threads            02:42:58
Load Avg:  0.25, 0.29, 0.15     CPU usage:  4.2% user, 4.6% sys, 91.2% idle
SharedLibs: num =   82, resident = 20.5M code, 2.89M data, 8.13M LinkEdit
MemRegions: num =  6337, resident =  111M + 40.7M private,  126M shared
PhysMem:   138M wired,  195M active,  302M inactive,  636M used, 1.38G free
VM: 8.29G + 48.6M   29545(0) pageins, 0(0) pageouts

  PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE
  327 top          7.0%  0:01.15   1    18    20   688K   832K  3.59M  27.0M 
  325 bash         0.0%  0:00.01   1    14    16   208K  1.20M   824K  27.1M
  324 login        0.0%  0:00.02   1    16    40   172K   964K   904K  26.9M
  320 ssh          0.0%  0:00.10   1    22    23   700K  1.40M  4.45M  27.4M
  318 sshfs-stat   0.0%  0:00.01   2    14    25   140K  1.05M   628K  28.0M

[snip]

(I wondered how much CPU time was being taken by sshfs-static.)

grahamperrin:~ gjp22$ which sshfs
/usr/local/bin/sshfs

grahamperrin:~ gjp22$ ls -l /usr/local/bin/sshfs
lrwxr-xr-x   1 gjp22  wheel  111 Apr 27 14:49 /usr/local/bin/sshfs -> 
/Applications/additions/m/
MacFusion/MacFusion.app/Contents/PlugIns/SSHFS.plugin/Contents/Resources/sshfs-s
tatic

### Terminal window 3 (read this alongside the other two)

grahamperrin:~ gjp22$ ls -l /Volumes/
total 8
lrwxr-xr-x   1 root  admin  1 May  1 02:38 MBP -> /

grahamperrin:~ gjp22$ sudo kill 318
Password:
grahamperrin:~ gjp22$ sudo kill -15 318
grahamperrin:~ gjp22$ sudo kill -9 318
grahamperrin:~ gjp22$ 

It wasn't until I opted for signal 9 
KILL (non-catchable, non-ignorable kill)
that the sshfs-static process was killed. 

Original comment by grahampe...@gmail.com on 1 May 2007 at 2:02

[GoogleCodeExporter]

At shutdown time, launchd attempts to terminate processes by sending them a 
SIGHUP. If 10 seconds pass and 
some processes are still existing, then a SIGTERM is sent. If further 10 
seconds pass and some processes still 
exists, a SIGKILL is set. Unless a process is "really hung", SIGKILL does the 
job because this signal cannot be 
caught. What you're seeing is an sshfs that doesn't die within the stipulated 
time.

Original comment by si...@gmail.com on 1 May 2007 at 2:05

[GoogleCodeExporter]

The obvious answer is that I should not omit the required mount point!

I guess that sshfs-static should, if no mount point is specified, either:

a) not run into a state that requires a kill with signal 9

(present the help screen in these circumstances?)

OR

b) default to an acceptable mount point 
/Volumes/{volumename}
or thereabouts.

Original comment by grahampe...@gmail.com on 1 May 2007 at 2:11

[GoogleCodeExporter]

Added extra check in mount code to see if a null mountpoint got through.

Original comment by si...@gmail.com on 1 May 2007 at 4:50

• Changed state: Fixed

[GoogleCodeExporter]

Thanks :-)

Original comment by grahampe...@gmail.com on 3 May 2007 at 10:58