15

Thanks sshfs magic, I can mount my home dir from a remote server with

sshfs user@server:/home/user ~/remote

Optimistically, I thought I'd set a local inotify-hook on ~/remote/logFile (in the sshfs mount) so a local program can react to remote log changes.

cd ~/remote
touch logFile                                # create remote file
inotifywait logFile &                        # set up local inotify-hook
ssh user@server -x touch /home/user/logFile  # touch file from remote

Nothing happens. inotifywait is silent unless I touch the file locally. Writing to a named pipe fails similarly.

Why is this?
How can I bridge this gap?

I could run inotifywait on the remote, hack up a file system change serialisation strategy and maintain a connection to the local, but then I'm basically reimplementing SSHFS. And it completely kills the abstraction.

Anko
  • 4,526
  • 2
    I don't think there's any way that inotify on the local system can detect changes on a remote filesystem. The local kernel is out of the loop in those changes. You need to run inotifywait on the server, not the client. – Barmar Jul 14 '14 at 16:27
  • @Barmar But then the client (local machine) won't know about changes. I edited to add a bit about that. – Anko Jul 15 '14 at 08:31
  • In general, network file systems are not able to provide complete transparency, they often break the abstraction. What's needed is an enhancement to SSHFS -- when you run inotify locally, it needs to send the request to the server, which runs inotify over there, and passes notifications back to the client. – Barmar Jul 15 '14 at 08:35
  • did you check out gamin? – Janus Troelsen Jul 19 '15 at 23:35
  • @JanusTroelsen I haven't heard of gamin. According to its overview page, it uses inotify too. Is it useful for distributing such updates over a network? – Anko Jul 19 '15 at 23:41

1 Answers1

15

THe SSHFS filesystem is built on top of the SFTP protocol. SFTP provides only facilities to manipulate files in “classical” ways; the client makes a request to the server (list a directory, upload a file, etc.), and the server responds. There is no facility in this protocol for the server to spontaneously notify the client that something has happened.

This makes it impossible to provide a facility such as inotify inside SSHFS. It would be possible to extend SSHFS with proprietary extensions, or to supplement it with a full-fledged SSH connection; but I don't know of any such extension to SSHFS.

Named pipes can't be implemented on top of SSHFS for the same reason. NFS, the classical networked filesystem, doesn't have any facility to support cross-machines named pipes either. On a networked filesystem, a named pipe creates an independent point of communication on each of the machines where it is mounted (in addition to the server).

FAM (the inotify analogue in SGI IRIX, which has been ported to Linux) provides a daemon which allows notifications to be sent over the network. Linux has rather deprecated FAM since inotify came onto the scene, so I don't know if getting FAM to run would be easier than rolling your own application-specific notification system. You'd need to set up some port forwarding over SSH or establish a VPN in order to secure the network link for FAM and NFS.

If you elect to roll your own, assuming that you're ok with giving the clients shell access, it's fairly easy to run an inotify monitor on behalf of a client: have the client open an SSH connection, and run the inotifywait command on the server, parsing its output on the client. You can set up a master connection to make it faster to open many connections from the same client to the same server.

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060