유닉스와 같은 멀티태스킹 운영체제에서 데몬(daemon, 발음: 데이먼/'deɪmən/ 또는 디먼 /'dimən/^[1])은 사용자가 직접적으로 제어하지 않고, 백그라운드에서 돌면서 여러 작업을 하는 프로그램을 말한다. 시스템 로그를 남기는 syslogd처럼 보통 데몬을 뜻하는 ‘d’를 이름 끝에 달고 있으며, 일반적으로 프로세스로 실행된다.

데몬은 대개 부모 프로세스를 갖지 않으며, 즉 PPID가 0이며, 따라서 프로세스 트리에서 init 바로 아래에 위치한다. 데몬이 되는 방법은 일반적으로 자식 프로세스를 포크(fork)하여 생성하고 자식을 분기한 자신을 죽이면서 init이 고아가 된 자식 프로세스를 자기 밑으로 데려가도록 하는 방식이다. 이러한 방법을 ‘fork off and die’라 부르기도 한다.

시스템은 시동할 때 데몬을 시작하는 경우가 많으며, 이런 데몬들은 네트워크 요청, 하드웨어 동작, 여타 프로그램에 반응하는 기능을 담당하게 된다. 그 밖에도 몇몇 리눅스에 있는 devfsd처럼 하드웨어 설정이나, cron처럼 주기적인 작업을 실행하는 등 기타 다양한 목적으로 사용된다.

데몬 프로세스 생성 방법

기술적으로 엄밀히 말하자면, 유닉스에서 부모 프로세스가 PID 1(init)이고 제어하는 터미널이 없을 때 그 프로세스를 데몬이라 할 수 있다. 부모 프로세스가 종료되면 init 프로세스가 그 프로세스를 받아 들인다. 데몬을 만들려면 보통 다음과 같은 과정이 필요하다.

• 프로세스를 제어하고 있는 터미널로부터 분리한다.
• 프로세스를 세션 리더로 만든다.
• 프로세스를 프로세스 그룹의 리더로 만든다.
• (한 번이나 두 번) 포크한 뒤 프로세스를 종료하여 자식 프로세스가 백그라운드에 남게 한다. 이 방법은 세션 리더를 만드는 데도 쓰이며, 부모 프로세스를 종료하지 않고 일반적인 작업을 수행할 수도 있다. 이 방법을 요약하여 ‘fork off and die’라고 한다.
• 루트 디렉터리("/")를 현재 작업 디렉터리로 만든다.
• umask를 0으로 변경해서 호출한 쪽의 umask와 상관 없이 open(), creat() 등의 호출을 수행할 수 있도록 한다.
• 상속받았으며, 부모 프로세스가 열고 있는 파일들을 자식 프로세스에서 모두 닫는다. 여기에는 0, 1, 2번 파일 서술자(각각 stdin, stdout, stderr)도 포함된다.
• 로그 파일이나 콘솔, 또는 /dev/null을 stdin, stdout, stderr로 설정한다.

마이크로소프트 도스 환경에서 이러한 프로그램은 램 상주 프로그램(TSR)의 형태를 취했다. 마이크로소프트 윈도에서는 데몬과 같은 역할을 하는 프로그램을 서비스라고 부르지만, 유닉스 계열의 영향을 받아 데몬이라고 부르는 경우도 있다. 클래식 맥 오에스에서는 이러한 프로그램을 시스템 확장이라 불렀으며, 유닉스 계열 운영 체제인 맥 오에스 텐에서는 데몬이 존재한다. (서비스도 존재하긴 하지만 전혀 다른 개념이다.)

A daemon process is usually defined as a background process that does not belong to a terminal session. Many system services are performed by daemons; network services, printing etc.

Simply invoking a program in the background isn't really adequate for these long-running programs; that does not correctly detach the process from the terminal session that started it. Also, the conventional way of starting
daemons is simply to issue the command manually or from an rc script; the daemon is expected to put itself into the background.

Here are the steps to become a daemon:

1. 
   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(), fails if you're a process group leader.
   
   
2. 
   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.
   
   
3. 
   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.
   
   
4. 
   chdir("/") to 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.]
   
   
5. 
   umask(0) so that we have complete control over the permissions of anything we write. We don't know what umask we may have inherited.
   
   [This step is optional]
   
   
6. 
   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. Note that many daemons use sysconf() to determine the limit _SC_OPEN_MAX.
   _SC_OPEN_MAX tells you the maximun open files/process. Then in a loop, the daemon can close all possible file descriptors. You have to decide if you need to do this or not. If you think that there might be file-descriptors open you should close them, since there's a limit on number of concurrent file descriptors.
   
   
7. 
   Establish new open descriptors for stdin, stdout and stderr. Even if you don't plan to use them, it is still a good idea to have them open. The precise handling of these is a matter of taste; if you have a logfile, for example, you might wish to open it as stdout or stderr, and open `/dev/null' as stdin; alternatively, you could open `/dev/console' as stderr and/or stdout, and `/dev/null' as stdin, or any other combination that makes sense for your particular daemon.
   
   

Almost none of this is necessary (or advisable) if your daemon is being started by inetd. In that case, stdin, stdout and stderr are all set up for you to refer to the network connection, and the fork()s and session manipulation should not be done (to avoid confusing inetd). Only the chdir() and umask() steps remain as useful.

출처 :  http://legendfinger.com/388