daemon(3) [osx man page]

DAEMON(3)						   BSD Library Functions Manual 						 DAEMON(3)

NAME

     daemon -- run in the background

LIBRARY

     Standard C Library (libc, -lc)

SYNOPSIS

     #include <stdlib.h>

     int
     daemon(int nochdir, int noclose);

DESCRIPTION

     The daemon() function is for programs wishing to detach themselves from the controlling terminal and run in the background as system daemons.
     On Mac OS X, the use of this API is discouraged in favor of using launchd(8).

     Unless the argument nochdir is non-zero, daemon() changes the current working directory to the root (/).

     Unless the argument noclose is non-zero, daemon() will redirect standard input, standard output, and standard error to /dev/null.

RETURN VALUES

     The daemon() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate
     the error.

ERRORS

     The daemon() function may fail and set errno for any of the errors specified for the library functions fork(2) and setsid(2).

SEE ALSO

     fork(2), setsid(2), sigaction(2)

HISTORY

     The daemon() function first appeared in 4.4BSD.

CAVEATS

     Unless the noclose argument is non-zero, daemon() will close the first three file descriptors and redirect them to /dev/null.  Normally,
     these correspond to standard input, standard output, and standard error.  However, if any of those file descriptors refer to something else,
     they will still be closed, resulting in incorrect behavior of the calling program.  This can happen if any of standard input, standard out-
     put, or standard error have been closed before the program was run.  Programs using daemon() should therefore either call daemon() before
     opening any files or sockets, or verify that any file descriptors obtained have values greater than 2.

     The daemon() function temporarily ignores SIGHUP while calling setsid(2) to prevent a parent session group leader's calls to fork(2) and then
     _exit(2) from prematurely terminating the child process.

BSD
								   June 9, 1993 							       BSD

GETLOGIN(2)						      BSD System Calls Manual						       GETLOGIN(2)

NAME

     getlogin, getlogin_r, setlogin -- get/set login name

LIBRARY

     Standard C Library (libc, -lc)

SYNOPSIS

     #include <unistd.h>

     char *
     getlogin(void);

     #include <sys/param.h>

     int
     getlogin_r(char *name, int len);

     int
     setlogin(const char *name);

DESCRIPTION

     The getlogin() routine returns the login name of the user associated with the current session, as previously set by setlogin().  The name is
     normally associated with a login shell at the time a session is created, and is inherited by all processes descended from the login shell.
     (This is true even if some of those processes assume another user ID, for example when su(1) is used).

     The getlogin_r() function provides the same service as getlogin() except the caller must provide the buffer name with length len bytes to
     hold the result.  The buffer should be at least MAXLOGNAME bytes in length.

     The setlogin() system call sets the login name of the user associated with the current session to name.  This system call is restricted to
     the super-user, and is normally used only when a new session is being created on behalf of the named user (for example, at login time, or
     when a remote shell is invoked).

     NOTE: There is only one login name per session.

     It is CRITICALLY important to ensure that setlogin() is only ever called after the process has taken adequate steps to ensure that it is
     detached from its parent's session.  Making a setsid() system call is the ONLY way to do this.  The daemon(3) function calls setsid() which
     is an ideal way of detaching from a controlling terminal and forking into the background.

     In particular, doing a ioctl(ttyfd, TIOCNOTTY, ...) or setpgrp(...) is NOT sufficient.

     Once a parent process does a setsid() system call, it is acceptable for some child of that process to then do a setlogin() even though it is
     not the session leader, but beware that ALL processes in the session will change their login name at the same time, even the parent.

     This is not the same as the traditional UNIX behavior of inheriting privilege.

     Since the setlogin() system call is restricted to the super-user, it is assumed that (like all other privileged programs) the programmer has
     taken adequate precautions to prevent security violations.

RETURN VALUES

     If a call to getlogin() succeeds, it returns a pointer to a null-terminated string in a static buffer, or NULL if the name has not been set.
     The getlogin_r() function returns zero if successful, or the error number upon failure.

     The setlogin() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indi-
     cate the error.

ERRORS

     The following errors may be returned by these calls:

     [EFAULT]		The name argument gave an invalid address.

     [EINVAL]		The name argument pointed to a string that was too long.  Login names are limited to MAXLOGNAME (from <sys/param.h>) char-
			acters, currently 17 including null.

     [EPERM]		The caller tried to set the login name and was not the super-user.

     [ERANGE]		The size of the buffer is smaller than the result to be returned.

SEE ALSO

     setsid(2), daemon(3)

STANDARDS

     The getlogin() system call and the getlogin_r() function conform to ISO/IEC 9945-1:1996 (``POSIX.1'').

HISTORY

     The getlogin() system call first appeared in 4.4BSD.  The return value of getlogin_r() was changed from earlier versions of FreeBSD to be
     conformant with ISO/IEC 9945-1:1996 (``POSIX.1'').

BUGS

     In earlier versions of the system, getlogin() failed unless the process was associated with a login terminal.  The current implementation
     (using setlogin()) allows getlogin to succeed even when the process has no controlling terminal.  In earlier versions of the system, the
     value returned by getlogin() could not be trusted without checking the user ID.  Portable programs should probably still make this check.

BSD
								   June 9, 1993 							       BSD