Re: --no-detach option?

2001-12-05 Thread Martin Pool

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?

2001-12-02 Thread Martin Pool

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?

2001-11-26 Thread Jos Backus

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?

2001-11-26 Thread Martin Pool

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?

2001-11-25 Thread Jeremy Hansen


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?

2001-11-25 Thread Jos Backus

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?

2001-11-22 Thread Andre Pang

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?

2001-11-21 Thread Dave Dykstra

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?

2001-11-21 Thread tim . conway

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?

2001-11-21 Thread Dave Dykstra

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?

2001-11-21 Thread Jos Backus

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?

2001-11-21 Thread Dave Dykstra

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?

2001-11-21 Thread Jos Backus

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;