On Mon, May 25, 2009 at 11:51 AM, Ritesh Raj Sarraf <[email protected]> wrote: > Package: sshfs > Version: 2.2-1 > Severity: normal > > > My requirement is something like this: > > I want to gather SysRq information from one of the host using a reliable > carrier and without touching the disk. > > netcat does give a proof-of-concept but isn't very reliable in reading > /proc/kmsg and transmitting the data. > > > So I tried sshfs. (I'm not sure if sshfs is expected to take care of > such scenarios also). > > I ran sshfs in debug mode: > build:~# sshfs -o debug,allow_root,direct_io 192.168.122.50:/proc > /var/tmp/foo/ > [email protected]'s password: > unique: 1, opcode: INIT (26), nodeid: 0, insize: 56 > INIT: 7.9 > flags=0x0000002b > max_readahead=0x00020000 > INIT: 7.8 > flags=0x00000001 > max_readahead=0x00020000 > max_write=0x00010000 > unique: 1, error: 0 (Success), outsize: 40 > > > And now when I access /proc/kmsg following is logged: > unique: 2, opcode: GETATTR (3), nodeid: 1, insize: 56 > unique: 2, error: 0 (Success), outsize: 112 > unique: 3, opcode: OPENDIR (27), nodeid: 1, insize: 48 > unique: 3, error: 0 (Success), outsize: 32 > unique: 4, opcode: READDIR (28), nodeid: 1, insize: 80 > unique: 4, error: 0 (Success), outsize: 4112 > unique: 5, opcode: READDIR (28), nodeid: 1, insize: 80 > unique: 5, error: 0 (Success), outsize: 720 > unique: 6, opcode: READDIR (28), nodeid: 1, insize: 80 > unique: 6, error: 0 (Success), outsize: 16 > unique: 7, opcode: RELEASEDIR (29), nodeid: 1, insize: 64 > unique: 7, error: 0 (Success), outsize: 16 > unique: 8, opcode: LOOKUP (1), nodeid: 1, insize: 45 > LOOKUP /kmsg > NODEID: 2 > unique: 8, error: 0 (Success), outsize: 136 > unique: 9, opcode: LOOKUP (1), nodeid: 1, insize: 45 > LOOKUP /kmsg > NODEID: 2 > unique: 9, error: 0 (Success), outsize: 136 > unique: 10, opcode: OPEN (14), nodeid: 2, insize: 48 > unique: 10, error: 0 (Success), outsize: 32 > OPEN[143850384] flags: 0x8000 /kmsg > unique: 11, opcode: FLUSH (25), nodeid: 2, insize: 64 > FLUSH[143850384] > unique: 11, error: 0 (Success), outsize: 16 > unique: 12, opcode: READ (15), nodeid: 2, insize: 80 > READ[143850384] 32768 bytes from 0 > > > And then when I wrote to /proc/sysrq-trigger, it just got hung: > unique: 13, opcode: GETATTR (3), nodeid: 1, insize: 56 > unique: 13, error: 0 (Success), outsize: 112 > unique: 14, opcode: OPENDIR (27), nodeid: 1, insize: 48 > unique: 14, error: 0 (Success), outsize: 32 > unique: 15, opcode: READDIR (28), nodeid: 1, insize: 80 > unique: 15, error: 0 (Success), outsize: 4112 > unique: 16, opcode: READDIR (28), nodeid: 1, insize: 80 > unique: 16, error: 0 (Success), outsize: 720 > unique: 17, opcode: READDIR (28), nodeid: 1, insize: 80 > unique: 17, error: 0 (Success), outsize: 16 > unique: 18, opcode: RELEASEDIR (29), nodeid: 1, insize: 64 > unique: 18, error: 0 (Success), outsize: 16 > unique: 19, opcode: LOOKUP (1), nodeid: 1, insize: 54 > LOOKUP /sysrq-trigger > NODEID: 3 > unique: 19, error: 0 (Success), outsize: 136 > unique: 20, opcode: LOOKUP (1), nodeid: 1, insize: 54 > LOOKUP /sysrq-trigger > NODEID: 3 > unique: 20, error: 0 (Success), outsize: 136 > unique: 21, opcode: SETATTR (4), nodeid: 3, insize: 128 > > I did was echo h > /var/tmp/foo/sysrq-trigger > echo never exits. > > Is this a buggy behavior ? > Or we can't expect this from sshfs ?
Does the host or client side kernel crash ? Or it is only a hang of process using sshfs file ? Regards -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
