monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] daemon support


From: Ben Walton
Subject: Re: [Monotone-devel] daemon support
Date: Sun, 16 Sep 2007 21:35:32 -0400

Ok, I've taken Ralf's suggestion and implemented a fallback daemon()
in case the target platform lacks it (I really don't know how
widespread this function is...).

I've added a win32 counterpart as well that will use daemon(3) if it
exists and simply return 0 (success) if not.  I've tested this on
Linux with HAVE_DAEMON set and unset.  All tests pass just fine.

Again, if anyone would be willing to test the nvm.daemon-support
branch on other platforms, I'd appreciate it.

Thanks
-Ben

On 9/11/07, Ben Walton <address@hidden> wrote:
> Thanks for this Ralf.  I'll look at it shortly.  I realize that I
> relied on the daemon call...I'm not sure as to the portability of this
> call, but it is common to Linux systems and (as cygwin relies heavily
> on linux libs/tools/etc) cygwin [I haven't built against cygwin though
> and don't know the details of the implementation underneath].  I'd be
> happy to make this better and will use your code below if that's the
> best path.
>
> Thanks!
> -Ben
>
> On 9/11/07, Ralf S. Engelschall <address@hidden> wrote:
> > On Mon, Sep 10, 2007, Ben Walton wrote:
> >
> > > I just synced a branch called nvm.daemon-support.  All tests are
> > > passing on my tree, but I've only got Ubuntu Feisty to test on right
> > > now.  I hope that someone can build/test it on more platforms (windows
> > > would be especially helpful).
> > >
> > > Let me know if you can help out.
> >
> > I've not built the sources on your branch, but in the commit notify
> > mails I see you are just calling the 4.4BSD function daemon(3).
> > Unfortunaely, IMHO this function is not portable enough for Monotone.
> >
> > You at least need some Autoconf glue for checking its availability
> > and provide --daemon only if daemon(3) is available or (my personal
> > preference) provide at least an own Unix fallback implementation of
> > daemon(3).
> >
> > I append you a possible fallback implementation of daemon(3) which I've
> > created some years ago based on STEVENS and related resources. Feel free
> > to take it over into Monotone's code base under the GPL if you wish.
> >
> > Also, for Windows I guess daemon(3) also doesn't exist, but I'm a
> > Unix-only hacker and have no clue about the Windows APIs and how it can
> > be emulated under Windows...
> >
> >                                        Ralf S. Engelschall
> >                                        address@hidden
> >                                        www.engelschall.com
> >
> > /*
> > **  my_daemon.c -- daemonize current process, fallback for daemon(3)
> > **  Copyright (c) 1999-2005 Ralf S. Engelschall <address@hidden>
> > */
> >
> > #include <fcntl.h>
> > #include <unistd.h>
> > #include <signal.h>
> > #include <sys/stat.h>
> > #include <sys/ioctl.h>
> >
> > int my_daemon(int nochdir, int noclose)
> > {
> >     int fd;
> >     int rc;
> >
> >     /* ignore tty related signals */
> > #ifdef  SIGTTOU
> >     signal(SIGTTOU, SIG_IGN);
> > #endif
> > #ifdef  SIGTTIN
> >     signal(SIGTTIN, SIG_IGN);
> > #endif
> > #ifdef  SIGTSTP
> >     signal(SIGTSTP, SIG_IGN);
> > #endif
> >
> >     /* fork so the parent can exit, this returns control to the command line
> >        or shell invoking your program. This step is required so that the new
> >        process is guaranteed not to be a process group leader (The next 
> > step,
> >        setsid, would fail if you're a process group leader). */
> >     rc = fork();
> >     switch (rc) {
> >         case -1: return -1;
> >         case  0: break;
> >         default: _exit(0); /* exit original process */
> >     }
> >
> >     /* setsid to become a process group and session group leader. Since a
> >        controlling terminal is associated with a session, and this new 
> > session
> >        has not yet acquired a controlling terminal our process now has no
> >        controlling terminal, which is a Good Thing for daemons. */
> > #ifdef HAVE_SETSID
> >     if (setsid() == -1)
> >         return -1;
> > #else
> >     if (setpgid(0, getpid()) == -1)
> >         return -1;
> > #ifndef _PATH_TTY
> > #define _PATH_TTY "/dev/tty"
> > #endif
> >     if ((fd = open(_PATH_TTY, O_RDWR)) == -1)
> >         return -1;
> >     ioctl(fd, TIOCNOTTY, NULL);
> >     close(fd);
> > #endif
> >
> >     /* fork again so the parent (the session group leader) can exit. This
> >        means that we, as a non-session group leader, can never regain a
> >        controlling terminal. */
> >     rc = fork();
> >     switch (rc) {
> >         case -1: return -1;
> >         case  0: break;
> >         default: _exit(0); /* exit original process */
> >     }
> >
> >     /* change to root directory ensure that our process doesn't keep
> >        any directory in use. Failure to do this could make it so that
> >        an administrator couldn't unmount a filesystem, because it was
> >        our current directory. [Equivalently, we could change to any
> >        directory containing files important to the daemon's operation.] */
> >     if (!nochdir)
> >         chdir("/");
> >
> >     /* give us complete control over the permissions of anything we
> >        write. We don't know what umask we may have inherited.
> >        [This step is optional] */
> >     umask(0);
> >
> >     /* close fds 0, 1, and 2. This releases the standard in, out, and
> >        error we inherited from our parent process. We have no way of
> >        knowing where these fds might have been redirected to. */
> >     if (!noclose && (fd = open("/dev/null", O_RDWR, 0)) != -1) {
> >         dup2(fd, STDIN_FILENO);
> >         dup2(fd, STDOUT_FILENO);
> >         dup2(fd, STDERR_FILENO);
> >         if (fd > 2)
> >             close(fd);
> >     }
> >
> >     return 0;
> > }
> >
> >
>
>
> --
> ---------------------------------------------------------------------------------------------------------------------------
> Ben Walton <address@hidden>
>
> When one person suffers from a delusion, it is called insanity. When
> many people suffer from a delusion it is called Religion.
> Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance
>
> ---------------------------------------------------------------------------------------------------------------------------
>


-- 
---------------------------------------------------------------------------------------------------------------------------
Ben Walton <address@hidden>

When one person suffers from a delusion, it is called insanity. When
many people suffer from a delusion it is called Religion.
Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance

---------------------------------------------------------------------------------------------------------------------------




reply via email to

[Prev in Thread] Current Thread [Next in Thread]