You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Guard use case:
I use guard and guard/listen to watch a mounted remote file system (samba using CIFS)
where CIFS unfortunately doesn't support inotify (and probably also would not in the future)
albeit samba itself does.
On system where the shared files are local, guard/listen is run in forwarding mode
and on the peers which should be informed about changes, guard is run
with --listen-on to listen on the sharing system.
Issue:
Letting listen daemon forward to 127.0.0.1 and listening on 127.0.0.1 works
(although it wouldn't really make sense except for debugging)..
However, when a remote address of the machine is used for forwarding,
listening on it doesn't work anymore, no notifications are received.
Debugging in pry indicates that listen.start() got stuck
and never returns (in contrast to listening to 127.0.0.1) (see further below).
Test was done on the same system (to eliminate interference with samba, etc):
After listener.start, execution hangs.
In contrast, using 127.0.0.1 would result in a normal return.
So listening on 127.0.0.1 works, listening on remote does not,
while telnet can receive the notifications in both cases, on 127.0.0.1 and on remote.
With best regards
The text was updated successfully, but these errors were encountered:
mechanicalduck
changed the title
Listener only listens on/connects to 127.0.0.1 (localhsot)
Listener only listens on/connects to 127.0.0.1 (localhost)
Aug 1, 2014
Guard use case:
I use guard and guard/listen to watch a mounted remote file system (samba using CIFS)
where CIFS unfortunately doesn't support inotify (and probably also would not in the future)
albeit samba itself does.
On system where the shared files are local, guard/listen is run in forwarding mode
and on the peers which should be informed about changes, guard is run
with --listen-on to listen on the sharing system.
Issue:
Letting listen daemon forward to 127.0.0.1 and listening on 127.0.0.1 works
(although it wouldn't really make sense except for debugging)..
However, when a remote address of the machine is used for forwarding,
listening on it doesn't work anymore, no notifications are received.
Debugging in pry indicates that listen.start() got stuck
and never returns (in contrast to listening to 127.0.0.1) (see further below).
Test was done on the same system (to eliminate interference with samba, etc):
On daemon:
$ listen --forward=192.168.100.120:4000 --verbose
On peer:
test.rb:
Nothing is printed after file notification on daemon
(using 127.0.0.1 in contrast works and 'change' is printed.)
But telnet can properly receive the notifications (interestingly they are send in plaintext by the way):
$ telnet 192.168.100.120 4000
(Note to the fellow debugger: Terminate the telnet session with key combination Ctrl-+)
After listener.start, execution hangs.
In contrast, using 127.0.0.1 would result in a normal return.
So listening on 127.0.0.1 works, listening on remote does not,
while telnet can receive the notifications in both cases, on 127.0.0.1 and on remote.
With best regards
The text was updated successfully, but these errors were encountered: