| Summary: | app-admin/lsyncd - add init.d and configuration files | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Hasan Karahan <hasan.karahan81> |
| Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
| Status: | UNCONFIRMED --- | ||
| Severity: | enhancement | CC: | bertrand, bircoph, dschridde+gentoobugs, orzel, randalla |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
init script & configuration plus sample lsyncd configuration
files/lsyncd.initd files/lsyncd.confd |
||
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. 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. an (optional) init.d script would be great, yes. Version 2.0.5 is out, by the way. 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. 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
Created attachment 361556 [details]
files/lsyncd.confd
v2 /etc/init.d/lsyncd
Remember to reassign the bugs when changing the maintainer |
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.