Archive for the ‘ Linux and internals, Networking ’ Category

Linux File System

Linux uses a whole different file system philosophy than Windows. Windows automatically assigns a drive letter to every partition and drive it finds. But Linux makes every partition and drive a subdirectory of the root (/) partition. If you are a Windows user, you may get confused when you try to use Linux. No matter how many partitions, hard drives, or floppy drives your computer has, the Linux File Manager displays everything in a single directory tree under the root directory indicated by a slash (/). Every partition or drive is “mounted” onto the directory tree, and appears in File Manager as a subdirectory.

Linux needs at least three partitions to work, the root partition, the /boot partition, and the swap partition. The root partition is mounted at startup. The root directory itself doesn’t contain any files, just subdirectories. The /boot partition contains files used to boot the system. The swap partition is used as “virtual memory”.

When the operating system needs more memory than there is available in the system’s RAM, it can use disk space to emulate memory. As the system operates, data is swapped back and forth between RAM and the swap partition. The swap partition doesn’t have a mount point because it’s a system file and is never accessed directly by the user.

Note: Linux, the Internet, and the rest of the computing world use forward slashes to form directory paths. Only Windows uses back-slashes to form directory paths. The back-slash also represents an ASCII escape character, resulting in all kinds of bugs in Windows programs. In Windows you just insert a floppy disk into the drive and it’s accessible. With Linux, before you can access devices such as a CD ROM or a floppy drive, you have to “mount” the drive. For example, to mount the floppy drive, insert the disk into the drive and then select Main Menu | Programs | System | Disk Manager. The “User Mount Tool” utility will appear. In the “User Mount Tool” click on the “Mount” button to the right of /dev/fd0.

Note: Linux abstracts every device attached your computer, including the hard drive and floppy drive as a file. Files in the /dev/ folder are equivalent to device driver files in Windows. Linux provides device files for most common devices, but if you install an uncommon device, you may need a special device file.

After mounting the drive, you can access the floppy disk. Before removing the disk, you have to “unmount” the drive. If you find yourself frequently mounting and unmounting drives, you can right-click on “Disk Manager” in the menu and select “Add this launcher to panel”.

When you installed Linux, information about devices on computer was stored in the file /etc/fstab. If the device that you want to mount was not configured during installation, use the LinuxConf utility to configure the device before you mount it.

For example, if you wanted to configure a floppy drive to access DOS floppy disks, insert a DOS floppy disk into the drive, then log in as root and open LinuxConf – Main Menu | Programs | System | LinuxConf. In the LinuxConf window Config tab, click on “+” next to “File systems” to open that branch. Under “File systems” click on “Access local drive”. The “Local volume” windows appears.

In the “Local volume” window, click on the Add button. The “Volume specification” window appears. In the “Partition” text box type /dev/fd0. Then click on the drop down button for the “Type” text box and select msdos. In the “Mount point” text box type /mnt/floppy. Click on the “Accept” button. Then click on the “Mount” button.

Note: To mount a partition or drive you have to use an existing subdirectory as the mount point. By convention, drives use the /mnt/ subdirectory as the mount point. To copy files to and from the mounted floppy diskArticle Search, drag and drop them to and from the directory /mnt/dosfloppy just as you would any other directory.


Configure a Linux Ntp Server

NTP server systems fall into two categories: primary reference servers and secondary reference servers. Primary reference servers use an external timing reference to provide time, such as GPS or radio clocks. Secondary reference servers synchronise with primary reference NTP servers and offer slightly reduced accuracy. Primary reference servers are designated stratum 1 servers, while secondary servers have a stratum greater than 1.

The NTP Distribution

The NTP source code is freely available from the Network Time Protocol web site. The current version available for download is 4.2.4. NTP is available for the Linux operating systems with ports available for Windows NT. Once the source code is downloaded, it should be configured, compiled and installed on the host machine. Many Linux operating systems, such as RedHat, offer NTP RPM packages.

Configuring NTP

The ‘ntp.conf’ file is main source of configuration information for a NTP server installation. Amongst other things, it contains a list of reference clocks that the installation is to synchronise. A list of NTP server references is specified with the ‘server’ configuration command thus:

server # NIST, Gaithersburg, Maryland NTP server

server # NIST, Boulder, Colorado NTP server

Controlling the NTP Server Daemon

Once configured, the NTP daemon can be started, stopped and restarted using the commands: ‘ntpd start’; ‘ntpd stop’ and ‘ntpd restart’. The NTP server daemon can be queried using the ‘ntpq -p’ command. The ntpq command queries the NTP server for synchronisation status and provides a list of servers with synchronisation information for each server.

NTP Access Control

Access to the NTP server can be restricted using the ‘restrict’ directive in the ntp.conf file. You can restrict all access to the NTP server with:

restrict default ignore

To only allow machines on your own network to synchronize with the server use:

restrict mask nomodify notrap

Multiple restrict directives can be specified in the ntp.conf file to restrict access to a specified range of computers.

Authentication Options

Authentication allows a matching passwords to be specified by the NTP server and associated clients. NTP keys are stored in the ntp.keys file in the following format: Key-number M Key (The M stands for MD5 encryption), e.g.:

1 M secret

5 M RaBBit

7 M TiMeLy


In the NTP configuration file ntp.conf, specify which of the keys specified above are trusted, i.e. are secure and you want to use. Any keys specified in the keys file but not trusted will not be used for authentication, e.g.:

trustedkey 1 7 10

The NTP server is now configured for authentication.

Client Configuration for Authentication

The client needs to be configured with similar information as the server, however, you may use a subset of the keys specified on the server. A different subset of keys can be used on different clients, e.g.:

Client A)

1 M secret

7 M TiMeLy

trustedkey 1 7

Client B)

1 M secret

5 M RaBBit

7 M TiMeLy


trustedkey 7 10

Essentially authentication is used by the client to authenticate that the time server is who he says he is, and that no rogue server intervenes. The key is encrypted and sent to the client by the server where it is unencrypted and checked against the client keys to ensure a match.

Linux Console – Virtual Terminal & Terminal Windows

There are several Linux terms that are the same or similar. And this “Linux Concepts & Terms Summary” article describes several terms that are the same – and others that are related.

Linux Terms: Linux Console, Linux Terminal and Linux Terminal Emulation Windows

First, You Need to Know About Linux Systems – With and Without Linux Desktops

You can install a Linux system with a desktop and this gives you a point-and-click working environment with icons and menus, like a Windows desktop – but much better!

Or you can install a Linux system without a desktop.

Linux tips: Linux servers are very often installed without a Linux desktop because a desktop is not required on some servers.

Linux Console and Linux Terminal

When you boot a Linux system without a desktop you see a black screen with a Login: prompt. This is commonly referred to as a Linux console.

At this point, you can log in as a Linux user and the Linux command line prompt appears. At this prompt, you can run Linux commands and Linux software programs.

A Linux console is also referred to as a Linux terminal.

Linux Terminal (Emulation) Windows

When you boot a Linux system that has a desktop installed, you boot to a GUI login prompt and log in to the Linux desktop.

At the Linux desktop, you can do some steps to open a terminal window on the desktop. A Linux terminal window is also know as a terminal “emulation” window. This window “emulates” a Linux terminal (a.k.a. console).

When you open a terminal emulation window, the Linux command line prompt appears and you can run Linux commands and Linux software programs.

Linux Tips: You can open multiple terminal emulation windows and hold down the Alt key and press the Tab key to move from one window to another.

Linux Virtual Terminal

From the Linux desktop, you can go to a Linux virtual terminal (a.k.a “vt”), that “emulates” the Linux terminal (a.k.a. console) that appears when you boot a Linux system that doesn’t have a desktop.

There are often six virtual terminals available and you press Ctrl+Alt+Fx to go to a virtual terminal. Replace the x in Fx with the number of a function key on your keyboard.

For example, to go from the Linux desktop to virtual terminal 1, hold down Ctrl and Alt and press F1 (and hope you don’t get a cramp). To go to vt 2, just press F2 instead of F1.

Linux Tips: You can’t access the virtual terminals from within some Linux virtual machines.

Imagine watching a Linux video tutorial that shows you all the steps described above, so you can easily learn how to work with all the different types of Linux terminals. Then pausing the video so you can try these steps yourself!

Daemon Process

What is a Daemon?

Every multitasking operating system supports a special type of process, a process that is usually kept a lower priority, performing a specific task over and over. Those processes are kept out of sight, performing their function in the background, without any direct intervention by the user. In the Unix operating system terminology, among other operating systems as well, background processes are called daemons.This tutorial will introduce you to daemon programming. You will write a simple daemon in Linux, C/C++ and a Bash Script, just to get a grip on what daemons are, and what they are capable of, only to move on to coding your first daemon in C. Daemons can be easily created under GNU/Linux, they mostly follow a specific convention. To begin coding your first daemon, you will need to find a use for it. Daemons can handle many tasks that could otherwise bother users and affect their productivity, which brings us to the next section. 

Putting Daemons to Use

Daemons usually handle tasks that require no user intervention, and consume low CPU power. CPU-intensive background tasks are not typically termed daemons, as bringing down computers to a sluggish performance can be hardly satisfying for any user, but decreasing the priority of these tasks can qualify them for that without sacrificing their performance, since CPUs are normally idle more than 90% of their time.A daemon usually handles a single task, and accepts commands through means of IPC (Inter-Process Communication), which you will be briefly exposed to in this tutorial. Tasks handled by daemons include serving web pages, transferring emails, caching name service requests, logging, and for the purposes of this site, serving game clients. 

Daemon game servers handle incoming game requests through a network, process these requests, update its persistent storage (database or flat files), and finally sends back responses to the clients. A major issue with game servers, among other servers, is that clients cannot be trusted, since a modified or reverse engineered version of the client can wreck havoc if the server is not ready to handle it. This enforces that clients should not keep a copy of the current game data, they should only send actions, not states, to the server, which would in turn validate those actions, and update the game status.

Structure of a Daemon

Daemons typically have the same structure, regardless of their functionality. A daemon starts off by initializing its variables. It then sets its IPC interface up, which could simply be signal handlers. The daemon then executes its body, which is almost always an infinite loop.Most daemons start off by forking. Forking is a method that allows a process to clone itself, creating an identical child. A daemon, as a parent process, usually forks off and terminates (or dies), while its child is left executing the main loop. The child is usually called an orphan process. In Unixes, orphan processes are automatically adopted by the “init” process, and this action is known as re-parenting. 

For a more practical approach, the following sections dissect the two previously mentioned daemons. Links to their sources are found at the end of the tutorial.

Writing a Daemon in Linux

In this tutorial, you will be introduced to creating daemons in Linux-based operating systems. The tutorial will cover the basic concepts underlying daemons, will guide you through the sample code of a daemon process, and then introduce you to what Inter-Process Communication is and how you could use it.

We need first to define what a daemon is. But then to do that, we would have to go a little farther, as far as source code is from a daemon. When you write a program, let us say in C, and you compile it, the compiler produces what you should probably already know as executable or binary. This created file, although it is executable, is not in fact entirely so. You do not just ask the operating system to start executing the first instruction in that file.

However, what actually happens is that the operating system loads this file into memory, and there it becomes known as a Process. A Process is different from that executable program you had on your disk drive, in that it is associated with information that the operating system uses to maintain running of the program. Without going into much detail, let us take a simple example to illustrate the difference between a program file on your disk and that same program when loaded into memory. Modern Operating Systems all support Multi-tasking; the ability to switch between two or more running processes. In a system with single a processor, the operating system actually switches between running processes, giving each a fraction of a second and thus giving you the illusion of several programs running simultaneously.

So, how does this example make a compiled binary different from processes!? Well, before the operating system switches from one running program to another, it has to save the first program’s state, so that it could return to the next correct instruction after it switches from the second. This is called the Program Counter, it is a counter that specifies which instruction the operating system has to execute next. Before switching to another running program, this Counter must be stored.

So, a process is not only the code contained in your binary program. It contains additional information that allows the operating system to maintain the running of that program. But how does this relate to daemons?

A daemon is a process, or more accurately, a background process. A daemon is not associated with any input or output streams, that is to say, you cannot give it input or read output from it interactively. And a daemon, a daemon does not have a parent process.

A parent process you may ask? Yes. In UNIX-like operating systems processes are structured in a tree. No process can actually emerge or come into existence from nowhere, it must be forked from a parent process. We have the “init” process as the root process, and any new process must fork from it or from one of its children.

So, if every process has a parent in that tree, where would our newly created daemon be placed!? Let us try to picture what would happen, by taking syslogd as an example (syslogd is the System Log Daemon. Though it should be apparent from its name, it is irrelevant to us what it actually does).

syslogd is stored on your disk drive as a program. When you start that program from the shell, the operating system loads it as a new process. Till now, it is no different from your standard computer program, it still can read input and produce output, and the shell is its parent process.

Then, syslogd would initiate a few steps to become a daemon: it forks from itself a new child process, and then kills the parent process. Since the parent was killed, and since our mighty Unix and Unix-like systems are too kind and could not leave an orphant process behind, “init” automatically adopts this newly forked process as its child.

Let us now jump into some code. The following code was adapted from syslogd.c:

pid = fork();
if (pid > 0)
else if (pid == 0) {

In the first line, our daemon process which we just ran forks itself, thus creating a new process. fork() is a system call that copies a process into another one, and then the former would be called the parent and the later would be called the child. fork()’s return value is different in the child process from the parent one. When the process is forked, the child process, which was just created, will start executing in the line just after the fork() call. Remember above we talked about the Program Counter being part of the Process, so when it is copied, that counter’s value is copied to the child as well.

Hence, we now have both processes, the parent and the child, positioned to execute the instruction after the fork() call. But what would distinguish them!?

In the parent process, fork() returns an Identifier that uniquely identifies the child process among all other processes running in the system, this identifier is known as the Process ID, or as usually abbreviated, PID. Meanwhile, in the child process, fork() returns 0.

Thus, what our daemon does is to check for the value returned by fork(). If this value was greater than 0, then it must have been executing within the parent process. If this value was 0, then we must have been executing within the child process.

Since we want this to be a background process, what we will do next is to exit the parent process. This way, our child process becomes orphan and gets adopted by init. In the shell, since the input and output streams were attached to a process that now exited, then we return to the prompt while the child process is still running in memory.

Or is it!? To go with further demonstration, let us consider the following program, which is basically the same as the one before but in a more complete form:


void daemon_entry_point()
 // Do Nothing

int main(int argc, char * argv)
 // fork this process and start the daemon
 pid_t pid = fork();

 if (0 > pid)
  // If the child was not succesfully, created,
  // -1 will be returned to the parent.

  printf("Failed to fork. Now exiting...\n");
 else if (0 < pid)
  // If the return value is larger than 0, then
  // this part of code will only be executed by
  // the parent. We exit the parent.

  printf("Process forked. Parent now exiting...\n");

 // Coming here, it must be the child, whose fork() returned 0.
 // What we now do is close the Standard File Descriptors since
 // we won't be reading or writing to them.

 printf("Daemon Starting...\n");


 // Call daemon_entry_point which would be responsible for
 // further initialization and startup routines for your daemon.


 return 0;

Now, compile this program

gcc -o my1stdaemon my1stdaemon.c

Run it


It should now have returned you back to the shell. At this point, the parent process have exited after forking the child, to see the child process running, type:

ps -e | grep my1stdaemon

ps is a program that reports a snapshot of information about the currently running processes. A sample output would be:

6894 pts/1    00:00:20 my1stdaemon

The first column shows the Process ID of the daemon. To shut the daemon down, we use that Process ID as follows:

kill -9 6894

This sends a KILL (9) signal to the daemon that forces it to exit.

Now that we have understood, written and tried our first daemon, we need to see how we can communicate with it. If a daemon cannot read or write from stdin, how could we tell it what to do and know what it is doing!?

This brings us to Inter-Process Communication!

Inter-Process Communication (IPC) refers to the set of mechanisms which we could use to make two processes to communicate with each other. There are several Inter-Process Communication methods, each has its own set of advantages and disadvantages. In this tutorial we would guide you throw using a FIFO, also known as a Named Pipe, to send data from one daemon to the other.

FIFOs, or Named Pipes, were created as an extension to Pipes, which later became known as Anonymous Pipes. Anonymous Pipes are an IPC mechanism that allow for uni-directional communication between two processes. Anonymous Pipes are a wildly popular mechanism for communication between processes, and can been seen in pipelines, where a set of processes are chained by their standard streams: the first one writes to its standard output, the second process reads from the first’s standard output and writes to it standard output, and so on. An example of a pipeline is our usage of the command “ps” above to pipe its output to the program “grep” which then outputted the result to the standard output stream.

So, what is a FIFO? A FIFO (First In First Out) is a Pipe that is associated with a file in your file system. Anonymous Pipes are different in that they have no name and do not persist after the process exists. With Named Pipes on the other hand, you have to specifically “unlink” or delete the file after you have no more need for it.

Now, what we want to do is to make my1stdaemon send the text “Hello World!” to a second daemon, my2nddaemon. This second daemon would then write the same text it received into a file /tmp/target.

To do this, we will first modify the function daemon_entry_point in my1stdaemon as follows:

void daemon_entry_point()
 // Create a FIFO (Named Pipe) in /tmp/myfifo
 mkfifo("/tmp/myfifo", 0644);

 // A FIFO is accessed exactly like a normal
 // file. Here, we would open it with "open"
 // and write to it with "write"

 int fifofd = open("/tmp/myfifo", O_WRONLY);

 if ( -1 == fifofd )

  // Since we already closed the standard
  // streams, we cannot print an error
  // message as usual. Before exiting, we
  // should have actually written to a log
  // file, but this has been left out for
  // simplicity.

 // Put some text in the FIFO, and sleep for 6
 // seconds. Repeat this for 10 times.

 char * text = "Hello World!\n";

 int i;
 for (i = 0; i < 10; i++)
  write(fifofd, text, strlen(text));

 // Close the FIFO

Now, compile my1stdaemon as before and run it. Open another shell window and type

cat /tmp/myfifo

There you would find that cat, which is another process, is in fact reading what we have written by my1stdaemon. One more thing, while you are there, type ls -l /tmp/myfifo, you would get:

prw-r--r--  1 leaf users 0 2006-07-25 22:56 /tmp/myfifo

The first character, ‘p’, indicates that the type of /tmp/myfifo is a Pipe, contrary to standard files which would be ‘-‘, and directories, which would be ‘d’.

Let us make our second daemon, that reads from the FIFO created by the first one. We will start our second daemon from the same code base, but will implement daemon_entry_point differently. Here is the implementation of this function for my2nddaemon

void daemon_entry_point()
 // Open the FIFO

 int fifofd = open("/tmp/myfifo", O_RDONLY);

 if ( -1 == fifofd )

 // Open a target file in which we would write
 // what we have read from the FIFO

 int targetfd = open("/tmp/target", O_WRONLY | O_CREAT, 0644);

 if ( -1 == targetfd )

 // Pipe the data from the FIFO to the target file.

 char text [50];
 memset(text, '', sizeof(text));

 int i;
 for (i = 0; i < 10; i++)
  read(fifofd, text, sizeof(text));
  write(targetfd, text, strlen(text));

 // Close the file handles

Compile this using

gcc -o my2nddaemon my2nddaemon.c

Run both daemons


Now, to see data while it is written to /tmp/target, type:

tail -f /tmp/target

That’s it.

You should now have an understanding of the basics you need to create a daemon in Linux, and how you can make this daemon communicate with other processes.

Fork off and Die: C/C++ Daemons


You’ll need to have GCC (The GNU Compiler Collection) installed. Enter “gcc –version” at the shell, and it should echo back the current GCC version. You will also need to have glibc, the GNU standard C library. You could try compiling a simple “Hello World” program just to make sure everything is setup properly, which is usually the case, but you should make sure anyway. Also, some hands-on experience with the C programming language will definitely prove useful.

The Code

The following code implements the very same daemon explained in the previous section, but using C. To compile your daemon, you first need to save the file under “uptlogd.c”. At the shell, enter “gcc -o uptlogd uptlogd.c” to compile and link your daemon. You can now use “./uptlogd” to start it.
// uptlogd - A simple C daemon







#define FILENAME_SIZE 15

#define LINE_SIZE_MAX 100

int logfd = -1;

int logging = 1;

char *logfile = NULL;

char *line = NULL;

The file basically has a little more includes than your average “Hello World” program! The header files are “stdio.h”, which defines “printf”, among other standard I/O functions, “unistd.h”, which defines lots of constants and functions, including “getpid”, “fork”, and others, “fcntl.h”, which defines the arguments used by the “open” function, “sys/types.h”, which defines several data types, among which is “pid_t”, “errno.h”, which is responsible for the basic error reporting facilities, and “signal.h” for handling signals.

The global variables are “logfd”, the file descriptor for the log file, “logging”, the logging flag, “logfile”, the name of the log file, and “line”, which temporarily holds the log message before it is written to the log file.

void trigger_logging(int signum)


	logging = (logging == 1) ? 0 : 1;


void clean_up(int signum)


	// Free up the resources

	if (logfd != -1)


	if (logfile != NULL)


	if (line != NULL)




Those two functions are defined as “callbacks”; they are called automatically when their associated signal is intercepted. The “trigger_logging” function enables/disables logging, while the “clean_up” function closes the file and deallocates the strings before exiting.

int main(int argc, char *argv[])


	// Fork off

	pid_t pid = fork();

	if (pid == -1)


		// Out of memory: not likely to happen!

		printf ("Error: not enough memory to initiate!\n");

		return 1;


	else if (pid != 0)


		// ... and die!

		printf("uptlogd PID is %d\n", (int) pid);

		printf("Logging started ...\n");

		return 0;


The main function starts off by forking through calling the “fork” function. “fork” returns -1 on failure, which only happens if not enough memory for cloning the current process is available, which is quite uncommon. “fork” returns the child PID in the parent’s thread, and zero in the child’s thread. Here, the parent outputs the child’s PID and exits, while the child continues to execute the remaining code.

	// Child continues executing here

	// Set the signal handlers up

	signal(SIGUSR1, trigger_logging);

	signal(SIGTERM, clean_up);

The “signal” function sets up a signal handler. The code handles SIGUSR1 by calling “trigger_logging”, and SIGTERM by calling “clean_up”, refer to those functions to get the whole picture.

	// Set the log file up

	pid = getpid();

	logfile = malloc(sizeof (char) * FILENAME_SIZE);

	sprintf(logfile, "LOGFILE_%06d", (int) pid);

	// Open the log file

	logfd = open(logfile, O_CREAT | O_WRONLY, 00644);

	if (logfd == -1)


		printf("%s\n", strerror(errno));

		return 1;


The log filename is allocated, and a unique name is used by concatenating the PID to the string “LOGFILE_”. A handle to the file is acquired using “open”. A defensive programming practice is to make sure the acquired file handles are valid, several problems can cause “open” to return -1.

	// Prepare the loop variables

	int count;

	int timesec = 0;

	line = malloc(sizeof (char) * LINE_SIZE_MAX);

	// Loop forever

	while (1) {

		// Write the log to the file, if logging is enabled

		if (logging == 1)


			sprintf(line, "Uptime: %d seconds\n", timesec);

			count = write(logfd, line, strlen (line));

			if (count == -1)


				printf("%s\n", strerror (errno));

				return 1;



		timesec += 5;

		// Sleep for 5 seconds



	return 0;


The daemon now executes its main loop. The loop starts by writing the log message, formatted in the “line” variable, to the log file. Another good programming practice is to check the length of the written message, which is the return value of “write”, compare with it the expected size, and act accordingly, but for simplicity purposes, the code only checks if the function failed. The daemon then updates its uptime, and sleeps for five seconds, only to repeat the loop all over again.

A Simple BASH Script Daemon


You will need to have BASH, which is the current default shell for most, if not all, Unixes. You also could use some basic BASH programming knowledge.

The Code

The following BASH code simply logs its uptime every five seconds to a file. As a quick introduction to signal trapping, the logging can be disabled and enabled while the daemon is running. To run the following script, you first need to save it under “”. Now, from the shell, type “chmod 755” to make the file executable, and “./ &” to run the file in the background.

# uptlogd - A simple BASH script daemon

# Daemon initialization

echo "uptlogd PID is $$"

echo "Logging started ..."


# Set the variables up



The daemon starts by printing its PID ($$). It then uses a unique name for its log file using its PID. Variable initializations follow, where logging is on, and the uptime is zero initially.

# Set the signal handler up

trap 'if [$logging==true]; then logging=false; else logging=true; fi' SIGUSR1

The trap command allows the daemon to intercept a signal and handle it. The daemon handles “SIGUSR1” by triggering the logging, enabling it if it is disabled, and vice versa.

# Loop forever

while true


	# Log the currently logged-in users if logging is enabled

	if [ $logging == true ]


		echo "Uptime: $timesec" >> $logfile


	timesec=`expr $timesec + 5`

	# Sleep for 5 seconds

	sleep 5


The daemon moves on to the main loop. It echoes the uptime to the log file if logging is enabled, updates its uptime, sleeps five seconds, and repeats. To interact with the daemon, you can use the “kill” command from the shell, which sends a signal to a running process. Using the PID reported by the daemon, use “kill ” to terminate the daemon by sending the default signal SIGTERM. You can also use “kill -SIGUSR1 ” to enable/disable logging.

The code is very simple, but who uses BASH to code daemons anyway..

15 interesting facts about LInux and Kernel

On 14th March 1994, Linux kernel version 1.0.0 was humbly released for the world to tinker with.

1. A 21 year-old Finnish college student created the Linux kernel as a hobby. (Do you know him?)

2. An asteroid was named after the creator of the Linux kernel.

3. Thousands of developers/programmers scattered all around the world are continuously contributing to the development of the Linux kernel.

4. The Linux kernel’s official mascot is a penguin named Tux.

5. According to a study funded by the European Union, the estimated cost to redevelop the most recent kernel versions would be at $1.14 billion USD.

6. As of today, only 2% of the Linux kernel has been written by Linus Torvalds.

7. The Linux kernel is written in the version of the C programming language.

8. Linux is now one of the most widely ported operating system kernels, running on a diverse range of systems from handheld computers to mainframe servers.

9. Linux kernel 1.0.0 was released with 176,250 lines of code. The latest Linux kernel has over 10 million lines of code.

10. Microsoft Windows and the Linux kernel can run simultaneously in parallel on the same machine using a software called Cooperative Linux (coLinux).

11. At first, Torvalds wanted to call the kernel he developed Freax (a combination of “free”, “freak”, and the letter X to indicate that it is a Unix-like system), but his friend Ari Lemmke, who administered the FTP server where the kernel was first hosted for downloading, named Torvalds’ directory linux.

12. A guy name William Della Croce, Jr. trademarked the name Linux and eventually demanded royalties for its use. He later agreed to assign the trademark to Torvalds.

13. The Linux kernel can be found on more than 87% of systems on the world’s Top 500 supercomputers.

14. A “vanilla kernel” is not an ice cream flavor but an unmodified version of the Linux kernel.

15. The Linux Kernel is not in any way related to the army rank called ‘Colonel’. (hehe)


Install Linux on USB stick (Pen drive)

USB Pendrive Linux install from Linux

The Pendrivelinux team has put together a USB Pen Drive Linux package based purely on Debian Linux. The USB Linux package is currently available in .img format. Installation is simple and just requires copying the .img to a USB device and then creating a live-rw partition if you wish to store your changes. We think you will find this personalized USB Linux version easy to install, navigate and use.

Credits extend to the Debian-Live team for creating Live-Helper script used in this project. (Aicrom) Márcio Santos for the custom Penguin artwork, Theme-Graphics thanks to Carlos

This Pendrivelinux version is obsolete and no longer supported.

Basic Essentials:

  • 1GB or larger USB flash drive (512MB will work but isn’t recommended)
  • Pendrivelinux.img
  • Linux environment (Debian used in this example)

Obtaining and installing Pendrivelinux to USB:

  1. Insert a 1GB or larger USB flash pen drive
  2. Start your PC (booting from a Linux OS)
  3. Download the pendrivelinux.img
  4. Open a terminal and type sudo su
  5. From the terminal, change to the directory where you saved pendrivelinux.img
  6. Type fdisk -l and note which device is your USB device. Example:/dev/sdX (X represents your USB drive letter. Through the rest of this tutorial, replace X with your actual drive letter)
  7. Type dd if=pendrivelinux.img of=/dev/sdX

Optional – Create a second partition for saving changes:

  1. Type fdisk /dev/sdX
    1. Type n (makes a new partition)
    2. Type p (makes the new partition a primary partition)
    3. Type 2 (makes this the 2nd primary partition)
    4. Hit enter to accept the default first cylinder
    5. Hit enter again to accept the default last cylinder
    6. Type w (writes the new partition information to the USB drive)
  2. Type umount /dev/sdX1 and then remove and reinsert your USB drive
  3. Type mkfs.ext2 -b 4096 -L live-rw /dev/sdX2
  4. Reboot your computer and set boot priority to boot from the USB stick

You should now be booting into USB Pen Drive Linux from your USB drive!

Notes: You must boot by typing live persistent at the boot prompt if you wish to use the second partition to save or restore changes. Otherwise the system will boot in LIVE mode.

No root password has been set by default. To set a root password open a terminal and type sudo passwd root and then set the password you would like to use for root access.

The default username is user. Default user password is live

Key Board Shortcut (Linux)

< Virtual terminals >

Ctrl + Alt + F1
Switch to the first virtual terminal. In Linux, you can have several virtual terminals at the same time. The default is 6.

Ctrl + Alt + Fn
Switch to the nth virtual terminal. Because the number of virtual terminals is 6 by default, n = 1…6.

Typing the tty command tells you what virtual terminal you’re currently working in.

Ctrl + Alt + F7
Switch to the GUI. If you have the X Window System running, it runs in the seventh virtual terminal by default in most Linux distros. If X isn’t running, this terminal is empty.
Note: in some distros, X runs in a different virtual terminal by default. For example, in Puppy Linux, it’s 3.

< X Window System >

Ctrl + Alt + +
Switch to the next resolution in the X Window System. This works if you’ve configured more than one resolution for your X server. Note that you must use the + in your numpad.

Ctrl + Alt + -
Switch to the previous X resolution. Use the – in your numpad.

Paste the highlighted text. You can highlight the text with your left mouse button (or with some other highlighting method, depending on the application you’re using), and then press the middle mouse button to paste. This is the traditional way of copying and pasting in the X Window System, but it may not work in some X applications.

If you have a two-button mouse, pressing both of the buttons at the same time has the same effect as pressing the middle one. If it doesn’t, you must enable 3-mouse-button emulation.

This works also in text terminals if you enable the gpm service.

Ctrl + Alt + Backspace
Kill the X server. Use this if X crashes and you can’t exit it normally. If you’ve configured your X Window System to start automatically at bootup, this restarts the server and throws you back to the graphical login screen.

< Command line – input >

Home or Ctrl + a
Move the cursor to the beginning of the current line.

End or Ctrl + e
Move the cursor to the end of the current line.

Alt + b
Move the cursor to the beginning of the current or previous word. Note that while this works in virtual terminals, it may not work in all graphical terminal emulators, because many graphical applications already use this as a menu shortcut by default.

Alt + f
Move the cursor to the end of the next word. Again, like with all shortcuts that use Alt as the modifier, this may not work in all graphical terminal emulators.

Autocomplete commands and file names. Type the first letter(s) of a command, directory or file name, press Tab and the rest is completed automatically! If there are more commands starting with the same letters, the shell completes as much as it can and beeps. If you then press Tab again, it shows you all the alternatives.

This shortcut is really helpful and saves a lot of typing! It even works at the lilo prompt and in some X applications.

Ctrl + u
Erase the current line.

Ctrl + k
Delete the line from the position of the cursor to the end of the line.

Ctrl + w
Delete the word before the cursor.

< Command line – output >

Shift + PageUp
Scroll terminal output up.

Shift + PageDown
Scroll terminal output down.

The clear command clears all previously executed commands and their output from the current terminal.

Ctrl + l
Does exactly the same as typing the clear command.

If you mess up your terminal, use the reset command. For example, if you try to cat a binary file, the terminal starts showing weird characters. Note that you may not be able to see the command when you’re typing it.

< Command line – history >

When you type the history command, you’ll see a list of the commands you executed previously.

ArrowUp or Ctrl + p
Scroll up in the history and edit the previously executed commands. To execute them, press Enter like you normally do.

ArrowDown or Ctrl + n
Scroll down in the history and edit the next commands.

Ctrl + r
Find the last command that contained the letters you’re typing. For example, if you want to find out the last action you did to a file called “file42.txt“, you’ll press Ctrl + r and start typing the file name. Or, if you want to find out the last parameters you gave to the “cp” command, you’ll press Ctrl + r and type in “cp“.

< Command line – misc >

Ctrl + c
Kill the current process.

Ctrl + z
Send the current process to background. This is useful if you have a program running, and you need the terminal for awhile but don’t want to exit the program completely. Then just send it to background with Ctrl+z, do whatever you want, and type the command fg to get the process back.

Ctrl + d
Log out from the current terminal. If you use this in a terminal emulator under X, this usually shuts down the terminal emulator after logging you out.

Ctrl + Alt + Del
Reboot the system. You can change this behavior by editing /etc/inittab if you want the system to shut down instead of rebooting.