PHP-Sync: Signal-Handling

[megabert]

Hi,

I'm setting up SFS on multiple nodes. What is disturbing a little bit is..

a) php-sync processes do not respond to SIGTERM, SIGHUP, SIGINT
b) php-sync-master process is not linked to forked processes

regarding a) Responding to standard signals

Expected behavior is that the processes are terminating cleanly after doing all open tasks after getting SIGTERM, or exiting with only critical cleanups at SIGINT. But there is no response at all. I have to use SIGABRT or an even higher priority signal to kill all processes.

Especially I would appreciate that in case of a TERM signal a running batch jobqueue is properly finished before terminating, which is causing me trouble in my personal setup at the moment.

regarding b) linking of forked processes

Expected behaviour is that a signal to the master php-sync process is propagated to the created childs, so only the master process has to be sent a signal. At the moment, as a workaround I'm grepping around in the process list, which does of course only work as long as the program names and titles does not change in the process list.

...and thank your for building and sharing SFS!

[lucabrunox]

Hello, thanks for your interest in SFS.

About a)
Every process handle SIGINT and SIGTERM currently, and they should exit. You should see a "Shutdown successful" log message, aren't you?
About batch job cleanup: If a batch job is not completed, it will be rerun when the sync is restarted. So that's the reason why we don't wait for the job to be complete. What's the problem in your specific setup?

About b)
All the processes belong to the same process group of the main process. That means you can, for example, kill -- -$PID which will send the signal to the whole process group, without grepping anything. Usually, the process group is the same as the pid of the main process.
Of course, it would be better if the main process would be responsible for propagating every signal to the children.

As for the sync itself, I'm thinking to rewrite it in go or some other language that is better suited for concurrency and networking. Thus avoiding the complexity of child process management and a number of other limitations due to the shared memory queues.

[mokraemer]

do you still support/use this tool, since the code is unchanged for some time?
I think I have the same needs as you had, so I'm willing to test this tool for productive use. With the current setup ssh as a transport layer (as used by lsyncd) could help for the move problem - as it was patched in their repos as well. Using ControlMaster minimizes the overhead.

I think some people may be looking for a tool like this but don't find it. but because of the tool-name, most of them only find "lsync" or "glusterfs" - maybe it would be good to have a more descriptive name.

For the question of go - I would currently stick to php and check if going into parallel is really a good idea.

[lucabrunox]

Yes we support this tool, we're using it in production. The fact that it sees few changes it's because it's doing fine as is for now. We change it mostly when we also need such changes in production, as well as issues on github.

About ssh, it should be already working if configured properly, it should be enough to add -e ssh to the rsync calls in the configuration, as well as ControlMaster as you say.
What "move" problem are you talking about?

Yes the name is a little unfortunate, we didn't change the name since its conception as we didn't think initially that we were going to open source it.

[mokraemer]

Ok, thanks for your reply. So I'll keep in touch how it is working, and maybe contribute, e.g. systemd-file.

ssh: yeah I've seen this config.
Rename: as stated on [https://github.com/immobiliare/sfs] "Renaming is slow". I was seeing this issue on lsyncd too, they are watching for file moves using inotify. In case of a move they don't use rsync, the do a "shell mv" operation which improves the speed dramtically if you move big files.

I'm really glad you did go open source.

[lucabrunox]

Renaming is slow only for directories. As described in the docs, renaming with a shell mv can lead to inconsistencies. In our case we chose consistency over performance. We never rename directories from within the fuse mount, because we don't have a use case for this.

If we have to, we just do the rename directly on the underlying filesystem of every node to make sure it's consistent and fast. It's something we do like... 1 or 2 times per year, or not at all.