Asynchronous Process Fail

Imagine a task that might be rather common in any IT landscape consisting of at least two servers, wherein one server is the publically accessible front end and an arbitrary number of other servers are kept secure behind a firewall.

The Challenge

A user is interacting with the publically accessible server — e.g. web server — and shall get an email containing a PDF document for an important transaction, e.g. an invoice. For data transmission to the secure host an XML interface is already running and the actual documents are sent via SFTP to the webserver by a cronjob. How do different groups implement an (a-)synchronous process to get those documents out by email?

The Challenge

The web developer

The web developer can happen to be ignorant of anything occuring outside of his framework, e.g. a webstore project written in PHP. Being drilled to write code that is executed upon an HTTP request the web developer prefers the easy way meaning being told when to do something.

The web developer would devise a special URL only accessible by the secure server, which the secure server has to visit in order to start the web developer's script.

The web developer's approach

The Linux enthusiast

The Linux enthusiast does not stop at scripts started by a HTTP request, but also considers the already available on board tools of a minimalistic or common Linux installation and loves the challenge to find easy and elegant solutions.

For the Linux enthusiast a web API is the wrong way to go as it is an additional source for programming errors and might be vulnerable to hacker attacks. For our friendly Linux enthusiast anything happening on a Linux machine is an event that can be used to trigger an action. The only question is how to harvest those events?

The Linux Way


The Linux enthusiast loves his cron and the variety of command line tools available. This allows him to monitor a directory for freshly uploaded documents and run a program for each of those files with a single line of shell script. On the other hand said program can be arbitrarily complex for formatting the mail text and putting some personal information into it.


If the process is not asynchronous enough or the delay between upload of the document and the mail sending cron is to long for our Linux enthusiast, there is even another alternative within the Linux kernel: Inotify.

Inotify is a Linux kernel subsystem that acts to extend filesystems to notice changes to the filesystem, and report those changes to applications. Thus our hasty Linux enthusiast can run his mail sending program almost immediately after a document has been uploaded.

The principle is comparable to the web developer's approach except that it is much more elegant as the web server's kernel itself triggers execution of the program.