Linux Daemons

Agenda What is a daemon What is a daemon What Is It Going To Do? What Is It Going To Do? How much interaction How much interaction Basic Daemon Structure Basic Daemon Structure Forking The Parent Process Forking The Parent Process Changing the file mode mask(umask) Changing the file mode mask(umask) Creating a unique session id (SID) Creating a unique session id (SID) Changing the working directory Changing the working directory Closing standard file descriptors Closing standard file descriptors Initialization, the big loop Initialization, the big loop

What is a daemon A daemon (or service) is a background process that is designed to run autonomously, with little or not user intervention. A daemon (or service) is a background process that is designed to run autonomously, with little or not user intervention.

What Is It Going To Do? A daemon should do one thing, and do it well. That one thing may be as complex as managing hundreds of mailboxes on multiple domains, or as simple as writing a report and calling sendmail to mail it out to an admin. A daemon should do one thing, and do it well. That one thing may be as complex as managing hundreds of mailboxes on multiple domains, or as simple as writing a report and calling sendmail to mail it out to an admin.

How much interaction Daemons should never have direct communication with a user through a terminal. In fact, a daemon shouldn't communicate directly with a user at all. All communication should pass through some sort of interface (which you may or may not have to write), which can be as complex as a GTK+ GUI, or as simple as a signal set. Daemons should never have direct communication with a user through a terminal. In fact, a daemon shouldn't communicate directly with a user at all. All communication should pass through some sort of interface (which you may or may not have to write), which can be as complex as a GTK+ GUI, or as simple as a signal set.

Basic Daemon Structure When a daemon starts up, it has to do some low- level housework to get itself ready for its real job. This involves a few steps: When a daemon starts up, it has to do some low- level housework to get itself ready for its real job. This involves a few steps: Fork off the parent process Fork off the parent process Change file mode mask (umask) Change file mode mask (umask) Open any logs for writing Open any logs for writing Create a unique Session ID (SID) Create a unique Session ID (SID) Change the current working directory to a safe place Change the current working directory to a safe place Close standard file descriptors Close standard file descriptors Enter actual daemon code Enter actual daemon code

Forking The Parent Process pid_t pid = fork(); if (pid < 0) {exit(EXIT_FAILURE);} if (pid > 0) {exit(EXIT_SUCCESS);}

Changing the file mode mask(umask) In order to write to any files (including logs) created by the daemon, the file mode mask (umask) must be changed to ensure that they can be written to or read from properly. This is similar to running umask from the command line, but we do it programmatically here. We can use the umask() function to accomplish this: In order to write to any files (including logs) created by the daemon, the file mode mask (umask) must be changed to ensure that they can be written to or read from properly. This is similar to running umask from the command line, but we do it programmatically here. We can use the umask() function to accomplish this:

Changing the file mode mask(umask) pid_t pid, sid; pid = fork(); if (pid < 0) {exit(EXIT_FAILURE); } if (pid > 0) { exit(EXIT_SUCCESS); } umask(0); By setting the umask to 0, we will have full access to the files generated by the daemon. Even if you aren't planning on using any files, it is a good idea to set the umask here anyway, just in case you will be accessing files on the filesystem. By setting the umask to 0, we will have full access to the files generated by the daemon. Even if you aren't planning on using any files, it is a good idea to set the umask here anyway, just in case you will be accessing files on the filesystem.

Creating a unique session ID (SID) pid_t pid, sid; pid = fork(); if (pid < 0) { exit(EXIT_FAILURE); } if (pid > 0) { exit(EXIT_SUCCESS); } umask(0); sid = setsid(); if (sid < 0) {exit(EXIT_FAILURE); }

Changing the working directory The current working directory should be changed to some place that is guaranteed to always be there. Since many Linux distributions do not completely follow the Linux Filesystem Hierarchy standard, the only directory that is guaranteed to be there is the root (/). We can do this using the chdir() function: The current working directory should be changed to some place that is guaranteed to always be there. Since many Linux distributions do not completely follow the Linux Filesystem Hierarchy standard, the only directory that is guaranteed to be there is the root (/). We can do this using the chdir() function:

Changing the working directory /*Code from previous slides*/ if ((chdir("/")) < 0) {exit(EXIT_FAILURE);} The chdir() function returns -1 on failure, so be sure to check for that after changing to the root directory within the daemon. The chdir() function returns -1 on failure, so be sure to check for that after changing to the root directory within the daemon.

Closing standard file descriptors One of the last steps in setting up a daemon is closing out the standard file descriptors (STDIN, STDOUT, STDERR). Since a daemon cannot use the terminal, these file descriptors are redundant and a potential security hazard. One of the last steps in setting up a daemon is closing out the standard file descriptors (STDIN, STDOUT, STDERR). Since a daemon cannot use the terminal, these file descriptors are redundant and a potential security hazard. The close() function can handle this for us: The close() function can handle this for us:

Closing standard file descriptors close(STDIN_FILENO); close(STDOUT_FILENO); close(STDERR_FILENO); close(STDIN_FILENO); close(STDOUT_FILENO); close(STDERR_FILENO);

Initialization, the big loop At this point, you have basically told Linux that you're a daemon, so now it's time to write the actual daemon code. Initialization is the first step here. At this point, you have basically told Linux that you're a daemon, so now it's time to write the actual daemon code. Initialization is the first step here. A daemon's main code is typically inside of an infinite loop. Technically, it isn't an infinite loop, but it is structured as one: A daemon's main code is typically inside of an infinite loop. Technically, it isn't an infinite loop, but it is structured as one:

Initialization, the big loop /* The Big Loop */ while (1) { /* Do some task here... */ sleep(30); /* wait 30 seconds */ }