Daemons and Services | Unix Application Migration Guide (Patterns & Practices)

A UNIX daemon is a process that provides a specific service or services. For example:

The inetd daemon listens for connections on certain Internet sockets.
The nfsd daemon implements the user -level part of the NFS (directory/file sharing) services.
The syslogd daemon provides system utilities that provide support for system logging and kernel message trapping.

On traditional UNIX systems, a daemon is a process that runs for an extended period of time, but does not have a controlling terminal. A Windows service is a background process that is similar to a daemon process. Daemons can be portedto the Interix subsystem by using the service interface.

Many daemons use setuid() or seteuid() to run as a particular user. This doesnot work on Windows, however, because of the way in which Windows securityis structured. A daemon invoked by inetd does not have these restrictions. It inherits the environment of the inetd process. In this context, the term daemon refers to a daemon process invoked by an Interix process that runs in the context of the Interix subsystem. An Interix service is an Interix process that is tied to the Win32 execution environment by the psxrun.exe program.

Code for traditional daemons is written differently from code for Windows services. Some of the rules for coding daemons can cause problems if they are applied to writing code for Windows services.

The Interix SDK contains the same daemon() interface that is found on BSD systems. Because the daemon() API uses fork() and setsid() , it should be used only in daemons that will be invoked by inetd or other master daemons.

Note	Interix includes ports of both the inetd and syslogd daemons and makes them available as Windows services.

Porting a UNIX Daemon to Interix

This section discusses porting a UNIX daemon to Interix and calling that daemon from either inetd or another master daemon. Daemons ported in this way cannotbe run as a Windows service. If a daemon needs to run as a Windows service, use the instructions in the next section, Porting a UNIX Daemon to an Interix Service.

When porting a daemon for UNIX to Interix, the daemon should already have the features described in the following list. For an example, see the code listing for a UNIX (and Interix) daemon in Example Interix Daemon Code later in this chapter.

A daemon must first use fork and then the parent process must exit. The child process created by the fork must then create a session and set the process group ID by calling setsid .

The fork() function is required because the current process is already a process group leader, which would otherwise cause the call to setsid() to fail. By using the call to setsid() in the child process, it becomes the leader of the new session and the process group leader of the new process group, and it has no controlling terminal. This is necessary for a daemon process. The parent process exits: It isno longer needed because the daemon code runs as the child.
The signal handling routine ( terminate in this case) is a common characteristicof a daemon process. By using it, the daemon can perform cleanup operations when it receives the SIGTERM signal (for example, when the system shuts down). To use the terminate handling routine, the daemon must call the sigaction () system call, which installs its signal handler for the SIGTERM signal.

Porting this daemon is a simple process. All that is needed is to recompile, relink, and execute the daemon from the command line.

– To port the daemon

Recompile and relink the UNIX daemon by using gcc :
```
  $ gcc -o msgd msgd.c   $ ./msgd  & 
```
Compile the test program found in Test Client for Interix Daemon (later in this chapter) by using the following command:
```
  $ gcc -o msg msg.c  
```

Launch the test application ( msg ) that will interact with the Interix daemonby entering the following command:

 $ ./msg

Output similar to the following appears. (Input is shown in bold.)

 Enter some text:  what  msgd received: WHAT Enter some text:  Where are we?!  msgd received: WHERE ARE WE?! Enter some text:  end  msgd received: END $

To obtain information about the Interix processes executing on the Windows-based system, enter the following command:

  $ ps ef

Notice that ./msgd is listed with a parent process of 1. This is the UNIX init process, the parent of all UNIX and Interix processes. Its primary role is to create processes from a script stored in the file /etc/inittab . It also controls autonomous processes required by any particular system.

Note	Interix does not use /etc/inittab because it does not support multiple run levels,as many UNIX systems do. /etc/inittab is used to coordinate tasks when changing between run levels.

Terminate the Interix daemon process by entering the following command:
```
  $ kill  <  pid of ./msgd  > 
```
(The PID of ./msgd is found under the PID heading.)

The msgd daemon is successfully ported to Interix.

The majority of daemons port directly to Interix, other coding issues apart.However, porting a daemon to an Interix service requires some changes, as discussed in Porting a UNIX Daemon to an Interix Service, following.

Porting a UNIX Daemon to an Interix Service

An Interix daemon has a number of limitations: It can be called only from a master daemon, and it is not integrated into the Windows service mechanisms. When a daemon is converted into a service, it can be managed from the Windows Control Panel Services item, as well as from the Interix command line.

Before going into more details on how to convert a daemon into a service, it is important to mention two commands that can help tie Interix processes to the Win32 execution environment:

The posix.exe program starts an Interix process with a controlling terminal.
The psxrun.exe program starts an Interix process without a controlling terminal.

In the case of a Windows service, the process must run without a controlling terminal, so psxrun is required.

Interix services can be administered by using the Windows Control Panel Services item or by using the service utility provided with Interix.

The service utility is used to install the service as a particular user and to stopthe service. The user name and password must be provided when the service is installed. If no user name is provided, the user defaults to LocalSystem, which provides an administrative login without network access. When a request to killa particular service comes from either the Windows Control Panel Services itemor from the service utility, psxrun sends the signal SIGTERM to the service.

Converting Daemon Code into Interix Service Code

To convert daemon code into Interix service code, the daemon code needs the following modifications:

Ensure that the service exits when it receives the SIGTERM signal.

It should catch the SIGTERM signal, clean up, and shut down. Ideally, the service should not spend more than a few seconds cleaning up. Otherwise, there canbe detrimental interactions with the Service Control Manager, such as lost communications.
Use the daemon() interface to create the service.

Using the daemon interface makes it easier to create the service because it causes the calling program to fork. Then, the parent exits and the child performs a setsid() . This disassociates the process from its current process group, session, and controlling terminal. On successful completion of this call, the process is the session leader of a group in which it is the only member, and the session has no controlling terminal.
Change the code so that it does not fork and then the parent exits.

If the parent process exits, psxrun treats the program as having exited, and the Windows Service Control Manager reports that the service was never successfully started.
Do not call setsid() to create a new session.

This does not work because of Windows Security. Use #ifdef to skip that code, and then replace it with a simple exec_asuser() call, or install the service as a particular user. The psxrun.exe program already ensures that the service process is a session leader.
Do not access network drives through drive- letters from the daemon.

Network drives are typically mounted on drive letters when a user logs in, then unmounted when that user logs out. A service program cannot depend on a given network drive being mounted on a given drive letter. If a service uses net.exe to mount a network drive, the drive letter it uses will become unavailable to interactive users, which may cause winlogon.exe to display error messages.If a service must access a network drive, reserve specific drive letters for exclusive use by the system.

For an example of these code and compilation steps, see the listing in Example Interix Service (later in this chapter), where the code in Example Interix Daemon Code has been converted into an Interix service.

Installing a Daemon as a Service

The service utility is required to install a daemon as a service. This utility can alsobe used to start and stop the service. The user name and password must be provided when the service is installed. If no user name is provided, the user defaults to LocalSystem, which provides an administrative login without network access. When a request comes from either Windows Control Panel Services or from the service utility to kill a particular service, psxrun sends the signal SIGTERM to the service. This is why the proper response to the SIGTERM signal is important.

To install and start the Windows (daemon) service, enter the following commands:

  $ service install ./wmsgd -s auto   $ service start wmsgd