<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Unix on Lloyd Rochester's Geek Blog</title><link>https://lloydroc.github.io/categories/unix/</link><description>Recent content in Unix on Lloyd Rochester's Geek Blog</description><generator>Hugo</generator><language>en</language><copyright>Copyright © 2025, Lloyd Rochester.</copyright><lastBuildDate>Sat, 08 Feb 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://lloydroc.github.io/categories/unix/index.xml" rel="self" type="application/rss+xml"/><item><title>Understanding Process Execution</title><link>https://lloydroc.github.io/post/c/execute-process/</link><pubDate>Tue, 29 Nov 2022 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/c/execute-process/</guid><description>&lt;h1 id="hahahugoshortcode20s0hbhb">Understanding Process Execution&lt;/h1>
&lt;p>In this post we will dive in to command execution from inside a program. The ability to execute commands from inside a program to obtain their output and exit code is very common for automation and testing use cases. Unfortunately, due to how Operating Systems work it is not a simple process to obtain the output and exit code from a running program.&lt;/p>
&lt;figure>&lt;img src="https://lloydroc.github.io/assets/png/remote-process-execution.png">&lt;figcaption>
 &lt;h4>Remote Process Execution&lt;/h4>
 &lt;/figcaption>
&lt;/figure>

&lt;p>Take for an example a program that from within we execute a command and capture the output in real time, as well as, capture the exit code once the program ends.&lt;/p></description></item><item><title>UART Theory and Programming on the Raspberry Pi</title><link>https://lloydroc.github.io/post/hardware/uart-raspberry-pi/</link><pubDate>Tue, 16 Aug 2022 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/hardware/uart-raspberry-pi/</guid><description>&lt;h1 id="hahahugoshortcode72s0hbhb">UART Theory and Programming on the Raspberry Pi&lt;/h1>
&lt;p>This post outlines how to control the UART in a Raspberry Pi using the C programming language. We will also explore parity checks and handling. Parity checking was the main driver for this post, however, if you&amp;rsquo;re looking for C code to control a UART that is also asynchronous please keep reading. This post contains a small command line tool that can asynchronously read and write to standard input and output through two connected UARTs. The command line tool has a number of options to set the speed, tty, parity and number of stop bits.&lt;/p></description></item><item><title>Understanding memory reallocation with realloc</title><link>https://lloydroc.github.io/post/c/understanding-realloc/</link><pubDate>Wed, 03 Aug 2022 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/c/understanding-realloc/</guid><description>&lt;h1 id="hahahugoshortcode36s0hbhb">Understanding memory reallocation with realloc&lt;/h1>
&lt;p>Let&amp;rsquo;s better understand how memory is allocated, then reallocated on the heap. When we allocate blocks of memory they are stacked on top of the heap with increasing memory addresses. What happens when we reallocate a memory block to make it larger when it&amp;rsquo;s isn&amp;rsquo;t the last item on the heap?&lt;/p>
&lt;h1 id="table-of-contents">Table of Contents&lt;/h1>
&lt;nav id="TableOfContents">&lt;/nav>
&lt;h1 id="heap-example">Heap Example&lt;/h1>
&lt;p>Let&amp;rsquo;s create an example using &lt;a href="https://man7.org/linux/man-pages/man3/malloc.3.html">malloc(3)&lt;/a> and &lt;a href="https://man7.org/linux/man-pages/man3/realloc.3p.html">realloc(3p)&lt;/a> that gives good insight. Here is how our example will play out:&lt;/p></description></item><item><title>Timer example in systemd</title><link>https://lloydroc.github.io/post/unix/systemd-timer-example/</link><pubDate>Sat, 09 Jul 2022 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/systemd-timer-example/</guid><description>&lt;h1 id="hahahugoshortcode95s0hbhb">Timer example in systemd&lt;/h1>
&lt;p>We can use &lt;code>systemd&lt;/code> instead of cron timers in Unix. Using &lt;code>systemd&lt;/code> timers is easy and provides numerous benefits over using Cron which are documented below. These timers more are complicated than cron, however, they are much more powerful.&lt;/p>
&lt;h1 id="creating-a-systemd-timer">Creating a &lt;code>systemd&lt;/code> timer&lt;/h1>
&lt;p>Let us look at the logical hierarchy of a timer on systemd and the files associated before we look at an example.&lt;/p>
&lt;h2 id="logical-requirements">Logical Requirements&lt;/h2>
&lt;p>To create a &lt;code>systemd&lt;/code> timer the following are required:&lt;/p></description></item><item><title>Differences between lists in Unix</title><link>https://lloydroc.github.io/post/unix/difference-lists/</link><pubDate>Mon, 27 Jun 2022 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/difference-lists/</guid><description>&lt;h1 id="hahahugoshortcode86s0hbhb">Differences between lists in Unix&lt;/h1>
&lt;figure>&lt;img src="https://lloydroc.github.io/assets/png/unix-comm-command.png">&lt;figcaption>
 &lt;h4>Unix comm command - Difference between two lists&lt;/h4>
 &lt;/figcaption>
&lt;/figure>

&lt;p>Using the &lt;a href="https://man7.org/linux/man-pages/man1/comm.1.html">comm(1)&lt;/a> command in Unix we can output the difference between &lt;strong>sorted&lt;/strong> lists. The &lt;code>comm&lt;/code> command takes two sorted files as inputs and will output lines unique in &lt;code>FILE1&lt;/code>, lines unique in &lt;code>FILE2&lt;/code> and lines common to &lt;code>FILE1&lt;/code> and &lt;code>FILE2&lt;/code>. The &lt;code>comm&lt;/code> command requires the files to be sorted.&lt;/p>
&lt;h1 id="examples">Examples&lt;/h1>
&lt;div class="highlight">&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-bash" data-lang="bash">&lt;span style="display:flex;">&lt;span> comm -12 file1 file2
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> Print only lines present in both file1 and file2.
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> comm -3 file1 file2
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span> Print lines in file1 not in file2, and vice versa.&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>
&lt;h1 id="example-with-files">Example with Files&lt;/h1>
&lt;p>Let&amp;rsquo;s see an example by creating two lists in file &lt;code>a.txt&lt;/code> and file &lt;code>b.txt&lt;/code>. Then use the &lt;code>comm&lt;/code> command to output what is only in &lt;code>a.txt&lt;/code>, in &lt;code>b.txt&lt;/code> and in both &lt;code>a.txt&lt;/code> and &lt;code>b.txt&lt;/code> - the union between them.&lt;/p></description></item><item><title>Unix Command for Epoch Time</title><link>https://lloydroc.github.io/post/unix/unix-command-epoch/</link><pubDate>Sun, 06 Feb 2022 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/unix-command-epoch/</guid><description>&lt;h1 id="hahahugoshortcode99s0hbhb">Unix Command for Epoch Time&lt;/h1>
&lt;p>This post provides some examples using the Unix &lt;a href="https://man7.org/linux/man-pages/man1/date.1.html">date(1)&lt;/a> command to interact with Epoch Time. We commonly need to print or parse the Epoch.&lt;/p>
&lt;h1 id="table-of-contents">Table of Contents&lt;/h1>
&lt;nav id="TableOfContents">
 &lt;ul>
 &lt;li>&lt;a href="#parse-the-epoch-in-mac-os-x">Parse the Epoch in Mac OS X&lt;/a>&lt;/li>
 &lt;/ul>
&lt;/nav>
&lt;h1 id="print-the-epoch">Print the Epoch&lt;/h1>
&lt;p>Using the Unix &lt;code>date&lt;/code> command we can print the Epoch. We need to use the &lt;code>%s&lt;/code> format.&lt;/p>
&lt;div class="highlight">&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;">&lt;code class="language-bash" data-lang="bash">&lt;span style="display:flex;">&lt;span>$ date +%s
&lt;/span>&lt;/span>&lt;span style="display:flex;">&lt;span>&lt;span style="color:#ae81ff">1644156059&lt;/span>&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>
&lt;p>The &lt;code>%s&lt;/code> format is &lt;em>seconds since the Epoch (1970-01-01 00:00 UTC)&lt;/em>. The Epoch is always in the UTC or &lt;em>Zulu&lt;/em> time zone.&lt;/p></description></item><item><title>USB 3D Sound on the Raspberry Pi</title><link>https://lloydroc.github.io/post/unix/raspberry-pi-3d-sound-alsa/</link><pubDate>Fri, 01 Jan 2021 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/raspberry-pi-3d-sound-alsa/</guid><description>&lt;h1 id="hahahugoshortcode92s0hbhb">USB 3D Sound on the Raspberry Pi&lt;/h1>
&lt;p>I recently bought the USB 3D Sound Card to play around with some C ALSA Programming on the Raspberry Pi. It worked without a problem and wanted to jot down some notes in this post on it&amp;rsquo;s specifications and how to use it. I didn&amp;rsquo;t have to make any modifications to the Raspberry Pi at all and sound worked right out of the box. I ran this on a Raspberry Pi B+ on Raspian.&lt;/p></description></item><item><title>Unix Process Tutorial</title><link>https://lloydroc.github.io/post/unix/unix-process-tutorial/</link><pubDate>Sat, 28 Nov 2020 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/unix-process-tutorial/</guid><description>&lt;h1 id="hahahugoshortcode100s0hbhb">Unix Process Tutorial&lt;/h1>
&lt;p>In this blog post I&amp;rsquo;ll go over a quick tutorial on Unix Processes. We&amp;rsquo;ll start with some theory and then go into some real world examples. It&amp;rsquo;s meant to be quick, to the point, and provide the necessary information to have a good understanding about how Unix Processes are designed.&lt;/p>
&lt;h1 id="sshing-into-a-unix-machine">SSH&amp;rsquo;ing into a Unix Machine&lt;/h1>
&lt;p>Let&amp;rsquo;s start with a common scenario. This scenario is to simply &lt;code>ssh&lt;/code> into another Unix machine. From a Unix process perspective what happens?&lt;/p></description></item><item><title>Retry in Bash</title><link>https://lloydroc.github.io/post/unix/bash-retry/</link><pubDate>Mon, 21 Sep 2020 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/bash-retry/</guid><description>&lt;h1 id="hahahugoshortcode88s0hbhb">Retry in Bash&lt;/h1>
&lt;p>In this blog post we&amp;rsquo;ll have two examples in &lt;code>bash&lt;/code> that will retry in the following ways:&lt;/p>
&lt;ul>
&lt;li>Retry a command N times before failing&lt;/li>
&lt;li>Retry command for X minutes before failing&lt;/li>
&lt;/ul>
&lt;p>In both of these examples we&amp;rsquo;ll use &lt;code>true&lt;/code> and &lt;code>false&lt;/code> as examples to test the script. These would need to be changed for your use case.&lt;/p>
&lt;h1 id="retry-a-command-x-times">Retry a Command X Times&lt;/h1>
&lt;p>A script to run a command N times. We will fail after 3 attempts, and delay for 10 seconds between attempts.&lt;/p></description></item><item><title>Systemd: Timers</title><link>https://lloydroc.github.io/post/unix/systemd_timers/</link><pubDate>Tue, 30 Jun 2020 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/systemd_timers/</guid><description>&lt;h1 id="hahahugoshortcode98s0hbhb">Systemd: Timers&lt;/h1>
&lt;p>In the fourth post on how to create a service in &lt;code>systemd&lt;/code> we will create a timer that will run every minute sending messages to our example &lt;code>foo&lt;/code> service over a socket. We&amp;rsquo;re essentially creating a &lt;code>cron&lt;/code> job socket client.&lt;/p>
&lt;p>Previous posts:&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://lloydroc.github.io/post/autotools/systemd-service-daemon-autotools/">Project Creation&lt;/a> of an autotools project and start/stop a daemon service.&lt;/li>
&lt;li>&lt;a href="https://lloydroc.github.io/post/unix/systemd_journal/">Journalling/Syslog&lt;/a> to enable logging, notify of state changes and accept reloads.&lt;/li>
&lt;li>&lt;a href="https://lloydroc.github.io/post/unix/systemd_sockets/">Socket&lt;/a> creation of a Unix Domain Socket for other processes to send messages to our service through remote procedure calls.&lt;/li>
&lt;/ul>
&lt;h1 id="what-the-example-will-do">What the example will do?&lt;/h1>
&lt;p>We already have a Unix Domain Socket created by &lt;code>systemd&lt;/code> that is listening on &lt;code>/var/log/foo.socket&lt;/code>. We also have a service called &lt;code>foo.service&lt;/code> that is listening to this socket . When messages are received on the socket the service will log them to the journal and syslog.&lt;/p></description></item><item><title>Systemd: A Service and a Socket</title><link>https://lloydroc.github.io/post/unix/systemd_sockets/</link><pubDate>Fri, 26 Jun 2020 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/systemd_sockets/</guid><description>&lt;h1 id="hahahugoshortcode97s0hbhb">Systemd: A Service and a Socket&lt;/h1>
&lt;p>This is the third post on how to create a &lt;em>service&lt;/em> in &lt;code>systemd&lt;/code>. See the &lt;a href="https://lloydroc.github.io/post/autotools/systemd-service-daemon-autotools/">first post&lt;/a> to create a autotools project and start/stop a daemon service. Or the &lt;a href="https://lloydroc.github.io/post/unix/systemd_journal/">second post&lt;/a> to enable logging, notify of state changes and accept reloads. In this post we&amp;rsquo;ll create a Unix Domain Socket so that other processes can send messages to our service through remote procedure calls.&lt;/p>
&lt;p>The socket we will use in this post is a Unix Socket with domain &lt;code>AF_UNIX&lt;/code> of type &lt;code>SOCK_DGRAM&lt;/code>. This type of socket is well suited for example purposes and is also ideal for remote procedure call applications. It is limited to communication on the same host, not over the internet. Unix Domain sockets are always reliable and are guaranteed to be delivered in order without duplication. Since this example uses a datagram socket we can receive the full message on each reception. Typically, the size of a datagram socket is under 2048 bytes see &lt;a href="https://www.man7.org/linux/man-pages/man7/socket.7.html">socket(7)&lt;/a> and look for the &lt;code>SO_SNDBUF&lt;/code> option for more details on maximum datagram size.&lt;/p></description></item><item><title>Status, Reloading and Journalling in Systemd</title><link>https://lloydroc.github.io/post/unix/systemd_journal/</link><pubDate>Tue, 23 Jun 2020 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/systemd_journal/</guid><description>&lt;h1 id="hahahugoshortcode96s0hbhb">Status, Reloading and Journalling in Systemd&lt;/h1>
&lt;p>This is the second post on how to create a &lt;em>service&lt;/em> in &lt;code>systemd&lt;/code>. In the &lt;a href="https://lloydroc.github.io/post/autotools/systemd-service-daemon-autotools/">first post&lt;/a> we created an &lt;em>autotools&lt;/em> project and were able to start, stop and get basic status on the service. In this post we&amp;rsquo;ll build on the &lt;em>autotools&lt;/em> project to add logging to &lt;code>syslog&lt;/code> and &lt;code>journald&lt;/code>. We will also give an example on how we could reload the service with a &lt;code>systemctl reload foo&lt;/code>. We will also use the &lt;a href="https://www.freedesktop.org/software/systemd/man/sd_notify.html#">sd_notify(3)&lt;/a> API to notify the service manager the status of what the service is doing.&lt;/p></description></item><item><title>Systemd and Autotools</title><link>https://lloydroc.github.io/post/autotools/systemd-service-daemon-autotools/</link><pubDate>Mon, 22 Jun 2020 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/autotools/systemd-service-daemon-autotools/</guid><description>&lt;h1 id="hahahugoshortcode8s0hbhb">Systemd and Autotools&lt;/h1>
&lt;p>This post starts a tutorial series on how to create a &lt;code>systemd&lt;/code> service in Linux. This first post is likely the hardest part as we create an &lt;a href="https://lloydroc.github.io/post/autotools/hello-world/">autotools&lt;/a> project with the source code and &lt;code>systemd&lt;/code> unit files. Having this setup in &lt;code>autotools&lt;/code> saves significant time installing unit files that &lt;code>systemd&lt;/code> requires, building our C code, installing, and uninstalling our program. If you can get through this first post the following posts should come easily.&lt;/p></description></item><item><title>I/O Multiplexing in Unix</title><link>https://lloydroc.github.io/post/unix/synchronous-io-multiplexing/</link><pubDate>Sun, 26 Apr 2020 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/synchronous-io-multiplexing/</guid><description>&lt;h1 id="hahahugoshortcode93s0hbhb">I/O Multiplexing in Unix&lt;/h1>
&lt;p>In Unix a process performs I/O on a single file descriptor at a time. When we talk about I/O on a file think &lt;code>read()&lt;/code> and &lt;code>write()&lt;/code> calls which are blocking. To get around blocking on a I/O call there are a number of ways. You can imagine how blocking on a single I/O call could bring the performance of a program to it&amp;rsquo;s knees. In this post we&amp;rsquo;ll quickly compare non-blocking I/O Models. Namely, &lt;code>select()&lt;/code>, &lt;code>poll()&lt;/code>, Signal Driven I/O, and &lt;code>epoll()&lt;/code>.&lt;/p></description></item><item><title>Unix Command Line Tool Timeline</title><link>https://lloydroc.github.io/post/unix/command-line-tool-timeline/</link><pubDate>Wed, 25 Mar 2020 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/command-line-tool-timeline/</guid><description>&lt;p>A compact timeline of Unix command line tools, ordered by the earliest release or broad adoption date.&lt;/p>
&lt;p>These entries focus on the core command line utilities that power Unix shells and classic Unix-style workflows. The list intentionally avoids large application suites, window managers, or programming languages used only incidentally as commands.&lt;/p>
&lt;h2 id="timeline">Timeline&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>Year&lt;/th>
 &lt;th>Tool&lt;/th>
 &lt;th>Notes&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>1971&lt;/td>
 &lt;td>&lt;code>sh&lt;/code>&lt;/td>
 &lt;td>The original Bourne shell, the foundation of Unix command-line scripting.&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>1971&lt;/td>
 &lt;td>&lt;code>cat&lt;/code>, &lt;code>cp&lt;/code>, &lt;code>mv&lt;/code>, &lt;code>rm&lt;/code>, &lt;code>ls&lt;/code>, &lt;code>mkdir&lt;/code>, &lt;code>rmdir&lt;/code>, &lt;code>pwd&lt;/code>, &lt;code>chmod&lt;/code>&lt;/td>
 &lt;td>Core file and directory utilities from early Unix releases.&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>1973&lt;/td>
 &lt;td>&lt;code>grep&lt;/code>&lt;/td>
 &lt;td>Pattern searching on files, one of the most widely used Unix commands.&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>1974&lt;/td>
 &lt;td>&lt;code>awk&lt;/code>&lt;/td>
 &lt;td>A powerful text-processing tool designed for Unix data manipulation.&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>1974&lt;/td>
 &lt;td>&lt;code>sed&lt;/code>&lt;/td>
 &lt;td>Stream editing for filtering and transforming text.&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>1974&lt;/td>
 &lt;td>&lt;code>find&lt;/code>&lt;/td>
 &lt;td>Recursive file discovery and selection.&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>1975&lt;/td>
 &lt;td>&lt;code>sort&lt;/code>, &lt;code>uniq&lt;/code>, &lt;code>cut&lt;/code>, &lt;code>paste&lt;/code>, &lt;code>head&lt;/code>, &lt;code>tail&lt;/code>&lt;/td>
 &lt;td>Classic text processing commands for pipeline workflows.&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>1975&lt;/td>
 &lt;td>&lt;code>tar&lt;/code>&lt;/td>
 &lt;td>Archive creation and extraction, important for backups and distribution.&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>1979&lt;/td>
 &lt;td>&lt;code>make&lt;/code>&lt;/td>
 &lt;td>Build automation for compiling and managing source trees.&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;h2 id="scope">Scope&lt;/h2>
&lt;p>This page is meant to capture the history of Unix-style shell tools, not every executable that happens to offer a CLI. If a tool feels like an integral Unix utility, it belongs here; if it is primarily a larger application or programming environment, it does not.&lt;/p></description></item><item><title>Daemon Example in C</title><link>https://lloydroc.github.io/post/c/unix-daemon-example/</link><pubDate>Thu, 05 Mar 2020 08:24:36 +0000</pubDate><guid>https://lloydroc.github.io/post/c/unix-daemon-example/</guid><description>&lt;h1 id="hahahugoshortcode37s0hbhb">Daemon Example in C&lt;/h1>
&lt;p>In this post we&amp;rsquo;ll look at daemon creation and demonstrate how to programmatically create daemons. We&amp;rsquo;ll go into the SysV recommendation of &amp;ldquo;double forking&amp;rdquo; for daemon creation.&lt;/p>
&lt;h1 id="table-of-contents">Table of Contents&lt;/h1>
&lt;nav id="TableOfContents">
 &lt;ul>
 &lt;li>&lt;a href="#creating-a-daemon-programmatically">Creating a daemon programmatically&lt;/a>&lt;/li>
 &lt;li>&lt;a href="#creating-a-daemon-with-systemd">Creating a daemon with Systemd&lt;/a>&lt;/li>
 &lt;li>&lt;a href="#using-glibcs-daemon-function-to-create-a-daemon">Using glibc&amp;rsquo;s daemon function to create a daemon&lt;/a>
 &lt;ul>
 &lt;li>&lt;a href="#analysis-of-the-daemon">Analysis of the Daemon&lt;/a>&lt;/li>
 &lt;/ul>
 &lt;/li>
 &lt;li>&lt;a href="#manually-creating-a-daemon-in-c-using-a-double-fork">Manually Creating a Daemon in C using a Double Fork&lt;/a>&lt;/li>
 &lt;li>&lt;a href="#c-code-double-fork-daemon-example">C Code &amp;ldquo;Double Fork&amp;rdquo; Daemon Example&lt;/a>
 &lt;ul>
 &lt;li>&lt;a href="#double-fork-steps">Double Fork Steps&lt;/a>&lt;/li>
 &lt;li>&lt;a href="#process-ids-from-a-double-fork">Process IDs from a Double Fork&lt;/a>&lt;/li>
 &lt;li>&lt;a href="#c-code-to-use-the-daemon-example">C Code to use the Daemon Example&lt;/a>&lt;/li>
 &lt;/ul>
 &lt;/li>
 &lt;li>&lt;a href="#header-file-for-daemon-example">Header file for Daemon Example&lt;/a>
 &lt;ul>
 &lt;li>&lt;a href="#header-file-for-daemon-example-1">Header file for Daemon Example&lt;/a>&lt;/li>
 &lt;/ul>
 &lt;/li>
 &lt;li>&lt;a href="#running-the-example">Running the example&lt;/a>
 &lt;ul>
 &lt;li>&lt;a href="#analyzing-the-daemon-process">Analyzing the Daemon Process&lt;/a>&lt;/li>
 &lt;/ul>
 &lt;/li>
 &lt;li>&lt;a href="#known-issues">Known Issues&lt;/a>&lt;/li>
 &lt;li>&lt;a href="#the-linux-programming-interface-book">The Linux Programming Interface Book&lt;/a>&lt;/li>
 &lt;li>&lt;a href="#where-to-go-from-here">Where to go from here?&lt;/a>&lt;/li>
 &lt;/ul>
&lt;/nav>
&lt;h1 id="what-are-daemons">What are Daemons?&lt;/h1>
&lt;p>Daemons are long running processes that run in the background with no controlling terminal - tty. Use cases for daemons are when the program needs to be available at all times and managed by the scheduler. Popular examples are nginx, postfix, httpd, sshd, cron, inetd. Many of these end in &amp;ldquo;d&amp;rdquo;, which is a convention for the name of a daemon. Daemons typically do not have the ability to write to &lt;code>stdout&lt;/code>, or &lt;code>stderr&lt;/code>, and have no means to connect to &lt;code>stdin&lt;/code> because they have no controlling terminal. Having no controlling terminal is a big deal in daemons. If they could connect to a controlling terminal they could be used in nefarious ways. We guarantee the daemon cannot take on a controlling terminal by doing the so-called &amp;ldquo;double fork&amp;rdquo;. Usually, output from the daemon is done by writing to log files. These logs are typically written in the in &lt;code>/var/log&lt;/code> directory. Input to a daemon, when necessary, is typically through sockets and signals. Let&amp;rsquo;s write an example daemon in C that runs on Unix.&lt;/p></description></item><item><title>Unix Virtual Network Device Types</title><link>https://lloydroc.github.io/post/unix/virtual_networking_device_types/</link><pubDate>Fri, 07 Feb 2020 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/virtual_networking_device_types/</guid><description>&lt;h1 id="hahahugoshortcode102s0hbhb">Unix Virtual Network Device Types&lt;/h1>
&lt;p>This blog post attempts to list and describe the majority of Virtual Network Device types in Unix. Networking with Linux is a hot topic especially in the IoT and Datacenter areas. Read on and you&amp;rsquo;ll see a large array of Device Types found in Unix.&lt;/p>
&lt;h2 id="background-on-network-configuration-in-unix">Background on Network Configuration in Unix&lt;/h2>
&lt;p>The &lt;code>iproute2&lt;/code> framework replaces &lt;code>ifconfig&lt;/code> as well as many other commands. The command family &lt;code>ip link&lt;/code> deals with network device configuration in Unix. We can use &lt;code>iproute2&lt;/code> to add, change, and delete network configurations. When adding a network using &lt;code>iproute2&lt;/code> we can do a &lt;code>ip link add name NAME type TYPE&lt;/code> where &lt;code>TYPE&lt;/code> is one of the many Linux Networking Device Types.&lt;/p></description></item><item><title>Creating IP Tunnels in Linux with iproute2</title><link>https://lloydroc.github.io/post/unix/iproute2_create_tunnel/</link><pubDate>Tue, 04 Feb 2020 07:40:31 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/iproute2_create_tunnel/</guid><description>&lt;h1 id="hahahugoshortcode90s0hbhb">Creating IP Tunnels in Linux with iproute2&lt;/h1>
&lt;p>In this post we&amp;rsquo;ll use &lt;em>iproute2&lt;/em> to create tunnels between two unix hosts. This will be the simplest form of an &lt;em>IP-in-IP&lt;/em> tunnel.&lt;/p>
&lt;h2 id="how-the-tunnels-will-work">How the Tunnels will work&lt;/h2>
&lt;p>In this example we have two Unix hosts with IP addresses &lt;em>10.255.254.96&lt;/em> and &lt;em>10.255.254.196&lt;/em> on a &lt;em>10.255.254.0/24&lt;/em> network and a gateway address of &lt;em>10.255.254.2&lt;/em>. These two hosts are on the same network. For this tunnel example we are going to add &lt;em>dummy&lt;/em> interfaces to each of our hosts and assign addresses &lt;em>192.168.2.111&lt;/em> and &lt;em>192.168.2.222&lt;/em> addresses to each of them respectively. Once the tunnels are up we will be able to send a ping from the first tunnel to the second tunnel as if the hosts are on the same network. This is known as encapsulation, since inside an IPv4 packet with a source of &lt;em>10.255.254.96&lt;/em> and destination of &lt;em>10.255.254.196&lt;/em> we have another IPv4 packet encapsulated inside with a source of &lt;em>192.168.2.111&lt;/em> and destination of &lt;em>192.168.2.222&lt;/em>.&lt;/p></description></item><item><title>pbcopy/pbpaste in WSL</title><link>https://lloydroc.github.io/post/unix/wsl-pbcopy-pbpaste/</link><pubDate>Tue, 30 Jul 2019 00:00:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/wsl-pbcopy-pbpaste/</guid><description>&lt;h1 id="hahahugoshortcode101s0hbhb">pbcopy/pbpaste in WSL&lt;/h1>
&lt;p>If you&amp;rsquo;re looking to replicate the pbcopy and pbpaste commands in WSL then you&amp;rsquo;ve found the right place! In this post we will make some simple shell scripts to replicate pbcopy and pbpaste in OS X. If you&amp;rsquo;re accustomed to pbcopy/pbpaste in Mac OS X, it&amp;rsquo;s hard to not have the equivalent in WSL. One spoiler alert the commands just are not as fast as they are in OS X.&lt;/p></description></item><item><title>Processing Emails with a script in Postfix</title><link>https://lloydroc.github.io/post/unix/process-mail-script-postfix/</link><pubDate>Sat, 27 Apr 2019 07:56:00 +0000</pubDate><guid>https://lloydroc.github.io/post/unix/process-mail-script-postfix/</guid><description>&lt;p>Updated Feb 7, 2020&lt;/p>
&lt;p>After thinking about this post more, it&amp;rsquo;s true you can process emails with a script in Postfix. The post provides the right answer to the &lt;strong>wrong question&lt;/strong>!! You can certainly process emails with Postfix but it&amp;rsquo;s hard, brittle, reduces performance and really isn&amp;rsquo;t recommended. What is better is to have a client program that reads the mail and does what you desire. This client can be put on a cron job, triggered or run however you want. The client is very flexible and so many different programming languages support them. This gives a lot of power to mark emails read, manage folders, etc &amp;hellip; It&amp;rsquo;s just a cleaner, better, easier to use and test architecture than having a script in Postfix. So I&amp;rsquo;ll leave this up, but, I wouldn&amp;rsquo;t use it unless there is some reason I cannot think of how it would be better.&lt;/p></description></item></channel></rss>