|Summary:||app-admin/lsyncd - add init.d and configuration files|
|Product:||Gentoo Linux||Reporter:||Hasan Karahan <hasan.karahan81>|
|Component:||Current packages||Assignee:||Patrick Lauer <patrick>|
|Severity:||enhancement||CC:||bertrand, bircoph, devurandom, orzel, randalla|
|Package list:||Runtime testing required:||---|
init script & configuration plus sample lsyncd configuration
Description Hasan Karahan 2011-05-23 20:26:44 UTC
Created attachment 274431 [details] init script & configuration plus sample lsyncd configuration lsyncd requires an init script, a configuration of the init script and an example lsyncd configuration; of which all a have been attached to this bug report. It should also be considered to install a default lsyncd user/group, under which the init script can run. This can be useful if lsyncd requires to access more than on server over ssh; in which case the various ssh key files to access the corresponding servers would be copied/linked into the home folder of the lsyncd user.
Comment 1 Jeremy Olexa (darkside) (RETIRED) 2011-05-24 23:32:57 UTC
Hello, A few comments: 1) lsyncd does not *require* an init script. I just use /etc/local.d/lsyncd.start 2) killall -q rsync seems very bad 3) I think it may be nicer to use the pidfile of lsyncd somehow. 4) What do you gain my creating a lsyncd user? You state less copies of ssh key but you could just as easily pass the path to the key in the conf file.
Comment 2 Hasan Karahan 2011-06-03 10:16:50 UTC
1) lsyncd does not *require* an init script. I just use /etc/local.d/lsyncd.start ++> Interesting; I did not know that you can use /etc/local.d for such purposes; but does this approach allow you to specify the dependencies (like a network being around)? Can you use init scripts here? From what I glimpsed I got the impression that you write here regular bash scripts; correct me if I'm wrong. Therefore I still think the more powerful init script have an advantage over /etc/local.d; 2) killall -q rsync seems very bad & 3) I think it may be nicer to use the pidfile of lsyncd somehow. ++> Jup, I agree with this and I tried to circumvent killall and use the pid files but I could only capture the pid of lsync and NOT rsync (since lsync start rsync processes in the background); therefore I had to fallback to the approach of killing all rsync processes (without checking if there is an actual dependency to lsync); 4) What do you gain my creating a lsyncd user? You state less copies of ssh key but you could just as easily pass the path to the key in the conf file. ++> Huummh, you may be right; let's forget about a specific lsyncd user.
Comment 3 Thomas Capricelli 2011-09-02 02:53:33 UTC
an (optional) init.d script would be great, yes. Version 2.0.5 is out, by the way.
Comment 4 Andrew Savchenko 2013-05-07 23:03:14 UTC
Hello, (In reply to comment #1) > 1) lsyncd does not *require* an init script. I just use > /etc/local.d/lsyncd.start Huh? The same way half of init.d-powered daemons doesn't require an init.d script and may be put into local.d, but it will be PITA, because: 1) No deps control. 2) No restart/reload/start/stop actions save as system boot/shutdown periods. And they are needed if lsyncd needs to be reconfigured or restarted/suspended for some other reason.
Comment 5 Bertrand Jacquin 2013-10-21 19:36:00 UTC
Created attachment 361554 [details] files/lsyncd.initd Here is v2 init script that is more generic : - By default use /etc/lsyncd.conf if user didn't define LSYNCD_CONFIG_FILE is conf.d/lsyncd - Migration to /run
Comment 6 Bertrand Jacquin 2013-10-21 19:36:22 UTC
Created attachment 361556 [details] files/lsyncd.confd v2 /etc/init.d/lsyncd
Comment 7 Pacho Ramos 2016-08-26 09:30:49 UTC
Remember to reassign the bugs when changing the maintainer