Yes, I could reproduce this with Lsyncd 1.34, and I can confirm the issue to be gone with 2.0.3.
To quote the strace man page: On some platforms a process that has a system call trace applied to it with the -p option will receive a SIGSTOP. This signal may interrupt a system call that is not restartable. This may have an unpredictable effect on the process if the process takes no action to restart the system call. Lsyncd 1.34 is such a process that does not properly do an action to restart the system call that reads from inotify. Lsyncd 1.42 will not halt, but do a complete restart, as it handles the SIGSTOP to be a SIGHUP. Lsyncd 2.0.x and later applies a proper signalmask and will thus not be affected when hooked with strace -p. Solution: For those who heavily use Lsyncd, I strongly suggest going and build a Lsyncd 2.0.x. It has been a complete rewrite that added improvments and fixes on a lot of frontiers. You need to change your config files though, the format has changed too. No XML anymore. If you strace Lsyncd 1.34 right from start rather than hook on it with strace -p it'll work too. Since this is a rather minor bug that is fixed already with later releases of Lsyncd and thus also will be fixed in the next debian release, I suppose no action is necessary. Kind regards, and sorry for the issues. Axel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
