Re: --no-detach option?
On 21 Nov 2001, Jos Backus [EMAIL PROTECTED] wrote: On Wed, Nov 21, 2001 at 08:54:18AM -0600, Dave Dykstra wrote: Here's a patch, based on Max Bowsher's patch. If deemed useful I will supply the man patch as well. --no-detach patch committed. -- Martin
Re: --no-detach option?
I'm starting to think we need to not show all the options in the default --help output. I think perhaps the default should be to show the commonly-used options (-avz, --include, : vs ::) and then have --help-options and so on for more details. It is getting quite ridiculous. There's one or two packages that do this, but I can't remember which ones right at the moment. -- Martin
Re: --no-detach option?
On Mon, Nov 26, 2001 at 07:37:33PM +1100, Martin Pool wrote: I'll apply something like Jos's patch, with a modification to not create another bloody global variable but instead stick it in an options struct. Good idea. Btw, Openssh also uses structs to pass options around. People who work with Apache should try the mostly-undocumented -X option, which tells it to not detach and also not fork on incoming connections. For debugging that's even more useful. off-topic Yes, however 2.0.28 still has a problem with this; see my message with subject ``HAVE_SETSID'' problem on the apache-dev list, which unfortunately has been ignored so far. I notified the maintainer of the FreeBSD port and he told me he has submitted a bugreport to the Apache folks. So hopefully this problem will be fixed at some point. The remaining issue with ``-X NO_DETACH'' is that it keeps httpd from creating its own process group, even though it _kills_ the process group it is in. This is bad news because this process group contains svscan/supervise/etc. So what is needed for httpd is another option that only causes apr_proc_detach() to call setsid()|setpgrp()|..., not the other stuff. All this is really ugly anyway; httpd should simply keep track of its children's pid's (I bet it does already) and kill() those instead of a process group it doesn't own. /off-topic S[ai]mple --no-detach manpage patch: Index: rsync.1 === RCS file: /cvsroot/rsync/rsync.1,v retrieving revision 1.95 diff -u -r1.95 rsync.1 --- rsync.1 14 Aug 2001 02:04:49 - 1.95 +++ rsync.1 26 Nov 2001 18:46:24 - @@ -296,6 +296,7 @@ --include-from=FILE don\'t exclude patterns listed in FILE --version print version number --daemonrun as a rsync daemon + --no-detach do not detach from the parent --address bind to the specified address --config=FILE specify alternate rsyncd\.conf file --port=PORT specify alternate rsyncd port number @@ -714,6 +715,10 @@ config file (/etc/rsyncd\.conf) on each connect made by a client and respond to requests accordingly\. See the rsyncd\.conf(5) man page for more details\. +.IP +.IP \fB--no-detach\fP +When running as a daemon, this option instructs rsync to not detach itself and +become a background process\. .IP .IP \fB--address\fP By default rsync will bind to the wildcard address -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: --no-detach option?
On 23 Nov 2001, Andre Pang [EMAIL PROTECTED] wrote: On Tue, Nov 20, 2001 at 03:05:32PM -0800, Jos Backus wrote: How about adding a --no-detach option (to be used in combination with supervise? If there's interest I'll provide a patch. Yes, this is great. I wanted it today when trying to debug IPv6. (Incidentally that now seems to work on Linux and at least compile on other interesting platforms; comments welcome.) I'll apply something like Jos's patch, with a modification to not create another bloody global variable but instead stick it in an options struct. People who work with Apache should try the mostly-undocumented -X option, which tells it to not detach and also not fork on incoming connections. For debugging that's even more useful. -- Martin
Re: --no-detach option?
Has any work been done to create an option for rsync to send its logging output to STDOUT for djb style logging? This would be a useful option for me. --log-stdout? Thanks -jeremy On Wed, 21 Nov 2001, Jos Backus wrote: On Wed, Nov 21, 2001 at 08:54:18AM -0600, Dave Dykstra wrote: Excuse me, I meant to say if stdin in IS a socket. That mode of operation is used when running from inetd or tcpserver. Not detaching from the parent is useful when one wants the parent (supervise in this case) to manage the rsync process instead. Here's a patch, based on Max Bowsher's patch. If deemed useful I will supply the man patch as well. Index: clientserver.c === RCS file: /cvsroot/rsync/clientserver.c,v retrieving revision 1.74 diff -u -r1.74 clientserver.c --- clientserver.c9 Nov 2001 06:58:39 - 1.74 +++ clientserver.c21 Nov 2001 19:26:45 - @@ -26,6 +26,7 @@ extern int read_only; extern int verbose; extern int rsync_port; +extern int no_detach; char *auth_user; int sanitize_paths = 0; @@ -500,7 +501,8 @@ return start_daemon(STDIN_FILENO); } - become_daemon(); + if (!no_detach) + become_daemon(); if (!lp_load(config_file, 1)) { exit_cleanup(RERR_SYNTAX); Index: options.c === RCS file: /cvsroot/rsync/options.c,v retrieving revision 1.62 diff -u -r1.62 options.c --- options.c 9 Sep 2001 04:41:14 - 1.62 +++ options.c 21 Nov 2001 19:26:46 - @@ -55,6 +55,7 @@ int am_sender = 0; int recurse = 0; int am_daemon=0; +int no_detach = 0; int do_stats=0; int do_progress=0; int keep_partial=0; @@ -203,6 +204,7 @@ rprintf(F, --include-from=FILE don't exclude patterns listed in FILE\n); rprintf(F, --version print version number\n); rprintf(F, --daemonrun as a rsync daemon\n); + rprintf(F, --no-detach do not detach from the parent\n); rprintf(F, --address bind to the specified address\n); rprintf(F, --config=FILE specify alternate rsyncd.conf file\n); rprintf(F, --port=PORT specify alternate rsyncd port number\n); @@ -285,6 +287,7 @@ /* TODO: Should this take an optional int giving the compression level? */ {compress,'z', POPT_ARG_NONE, do_compression}, {daemon, 0, POPT_ARG_NONE, am_daemon}, + {no-detach,0, POPT_ARG_NONE, no_detach}, {stats,0, POPT_ARG_NONE, do_stats}, {progress, 0, POPT_ARG_NONE, do_progress}, {partial, 0, POPT_ARG_NONE, keep_partial}, -- The trouble with being poor is that it takes up all your time.
Re: --no-detach option?
On Sun, Nov 25, 2001 at 06:27:57PM -0500, Jeremy Hansen wrote: Has any work been done to create an option for rsync to send its logging output to STDOUT for djb style logging? This would be a useful option for me. --log-stdout? I'm assuming that rsync currently uses syslog(3), yes? Yes, it would be a useful option imo. Let's first see if the --no-detach option makes it in though, we can then add this other option. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: --no-detach option?
On Tue, Nov 20, 2001 at 03:05:32PM -0800, Jos Backus wrote: How about adding a --no-detach option (to be used in combination with --daemon) to rsync so it can be run under Dan Bernstein's daemontools' supervise? If there's interest I'll provide a patch. I'd be interested in this; sure. The real question is whether Dave/Martin/the other rsync maintainers would be interested in it, too :). I think it should be included, since the patch is non-invasive and doesn't break compatiblity. It would probably be beneficial even for people who don't use daemontools. -- #ozone/algorithm [EMAIL PROTECTED] - trust.in.love.to.save
Re: --no-detach option?
On Wed, Nov 21, 2001 at 12:23:29PM -, Max Bowsher wrote: I did the same, for cygwin, but I called the option --debug-daemon. --no-detach is probably a better name. Heres my patch. - Original Message - From: Jos Backus [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 20, 2001 11:05 PM Subject: --no-detach option? How about adding a --no-detach option (to be used in combination with --daemon) to rsync so it can be run under Dan Bernstein's daemontools' supervise? If there's interest I'll provide a patch. Rsync will already not detach if stdin is not a socket. Is that sufficient? - Dave Dykstra
Re: --no-detach option?
Not in daemon mode. = # ps -ef |grep rsync # rsync --daemon # ps -ef |grep rsync root 23716 1 0 07:42:58 ?0:00 rsync --daemon # rsync localhost:: tconway # Like most daemons, it forks by default. I've wanted this feature for some time, for debugging, but instead, just started it with truss, with the fork option. Tim Conway [EMAIL PROTECTED] 303.682.4917 Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, n9hmg on AIM perl -e 'print pack(, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), .\n ' There are some who call me Tim? Dave Dykstra [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/21/2001 07:15 AM To: [EMAIL PROTECTED] cc: (bcc: Tim Conway/LMT/SC/PHILIPS) Subject:Re: --no-detach option? Classification: On Wed, Nov 21, 2001 at 12:23:29PM -, Max Bowsher wrote: I did the same, for cygwin, but I called the option --debug-daemon. --no-detach is probably a better name. Heres my patch. - Original Message - From: Jos Backus [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 20, 2001 11:05 PM Subject: --no-detach option? How about adding a --no-detach option (to be used in combination with --daemon) to rsync so it can be run under Dan Bernstein's daemontools' supervise? If there's interest I'll provide a patch. Rsync will already not detach if stdin is not a socket. Is that sufficient? - Dave Dykstra
Re: --no-detach option?
Excuse me, I meant to say if stdin in IS a socket. - Dave Dykstra On Wed, Nov 21, 2001 at 07:46:29AM -0700, [EMAIL PROTECTED] wrote: Not in daemon mode. = # ps -ef |grep rsync # rsync --daemon # ps -ef |grep rsync root 23716 1 0 07:42:58 ?0:00 rsync --daemon # rsync localhost:: tconway # Like most daemons, it forks by default. I've wanted this feature for some time, for debugging, but instead, just started it with truss, with the fork option. Tim Conway [EMAIL PROTECTED] 303.682.4917 Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, n9hmg on AIM perl -e 'print pack(, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), .\n ' There are some who call me Tim? Dave Dykstra [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/21/2001 07:15 AM To: [EMAIL PROTECTED] cc: (bcc: Tim Conway/LMT/SC/PHILIPS) Subject:Re: --no-detach option? Classification: On Wed, Nov 21, 2001 at 12:23:29PM -, Max Bowsher wrote: I did the same, for cygwin, but I called the option --debug-daemon. --no-detach is probably a better name. Heres my patch. - Original Message - From: Jos Backus [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 20, 2001 11:05 PM Subject: --no-detach option? How about adding a --no-detach option (to be used in combination with --daemon) to rsync so it can be run under Dan Bernstein's daemontools' supervise? If there's interest I'll provide a patch. Rsync will already not detach if stdin is not a socket. Is that sufficient? - Dave Dykstra
Re: --no-detach option?
On Wed, Nov 21, 2001 at 08:54:18AM -0600, Dave Dykstra wrote: Excuse me, I meant to say if stdin in IS a socket. That mode of operation is indeed useful when running rsync --daemon from inetd or tcpserver. I am talking about a mode in which rsync still listen()s, etc. but can be managed by its parent (supervise in the daemontools case). -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: --no-detach option?
On Wed, Nov 21, 2001 at 11:07:21AM -0800, Jos Backus wrote: On Wed, Nov 21, 2001 at 08:54:18AM -0600, Dave Dykstra wrote: Excuse me, I meant to say if stdin in IS a socket. That mode of operation is indeed useful when running rsync --daemon from inetd or tcpserver. I am talking about a mode in which rsync still listen()s, etc. but can be managed by its parent (supervise in the daemontools case). I'm not familiar with daemontools; I checked the web site and it wasn't obvious to me. What's the advantage of using daemontools supervise? Why does it need to run the daemon as a subprocess? Assuming it's a command to make sure a daemon keeps running, it seems to me that it ought to be able to work if given a process id and not require any deaemon it could supervise to be modified to not fork. I have a script for my own use which does that. - Dave Dykstra
Re: --no-detach option?
On Wed, Nov 21, 2001 at 03:27:52PM -0600, Dave Dykstra wrote: I'm not familiar with daemontools; I checked the web site and it wasn't obvious to me. What's the advantage of using daemontools supervise? Why does it need to run the daemon as a subprocess? Like AIX's SRC (System Resource Controller), svscan/supervise together with svc/svstat are designed to control daemons in a uniform, platform-independent way. So rather than having start|stop scripts (/etc/rc?.d/*, /etc/rc.local, etc.) for each daemon, a service scanner (svscan) runs which starts supervise processes, which in turn manage each individual service. By virtue of supervise being the parent of the service being managed, problems with stale pidfiles and such are being avoided. A simple example: traitor:/service% ls -l sshd lrwxr-xr-x 1 root wheel 17 May 7 2001 sshd - /var/service/sshd traitor:/service% ls -l /var/service/sshd total 3 drwxr-xr-x 4 nobody wheel 512 May 7 2001 log -rwxr-xr-x 1 rootwheel 91 May 7 2001 run drwx-- 2 rootwheel 512 Nov 21 13:48 supervise traitor:/service% cat /var/service/sshd/run #!/bin/sh PATH=/usr/sbin exec sshd -D -e 21 The service can be controlled (up/down/restart/run once) using the svc command. Among others, one thing this setup makes easy is for a privileged process to be controlled by an unprivileged group of users, by simply manipulating the permissions on the service control socket. Assuming it's a command to make sure a daemon keeps running, it seems to me that it ought to be able to work if given a process id and not require any deaemon it could supervise to be modified to not fork. I have a script for my own use which does that. It does more than just that. Hope this explains things a little bit. - Dave Dykstra -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;