Brightbox Blog

Brightbox Kubernetes 1.35

2026-03-25T00:00:00Z

We’re now supporting Kubernetes through to version 1.35.

That means new versions of our Kubernetes Cloud Controller, which provides tighter integration with Brightbox, adding Brightbox-specific details to the nodes in Kubernetes, labelling them with the zone, image type and the cloud addressing details and integrates with our Load Balancer service as an ingress controller.

And we’ve updated our Kubernetes cluster terraform manifests too, which helps you setup and manage a full auto-scaling Kubernetes cluster directly on Brightbox Cloud.

Kubernetes 1.35 brings a few really useful features but here’s a couple that stand out to me:

In-place vertical scaling of pods

In-place vertical scaling of pods is now stable, so you can increase cpu and ram on pods without having to restart them. Kubernetes makes it easy to avoid downtime during restarts, but it’s still nice to be able to avoid them sometimes!

PreferSameNode traffic distribution

PreferSameNode traffic distribution is now stable too, which can really help with performance by keeping traffic within the same node when possible. Up until now, in the extreme cases, we’ve been solving this problem by running some services as sidecars which solves the problem but means you’re often over-provisioning services. Also note that PreferClose has become PreferSameZone.

Pod-Level Resource Requests

This actually came along with 1.34 and is still in beta in 1.35, but it’s useful when you have a pod with multiple containers that make up one service and don’t want to have to think about specifically allocating cpu or ram to them individually. One example for us is running high load php apps, where we have separate apache and php-fpm containers. It makes no sense to be requesting/limiting apache cpu usage separately to php.

Ordered namespace deletion

Again, this actually came up in 1.34 but it’s worth a mention. Deleting namespaces should no longer result in stuck namespaces due to problems with finalizers!

Upgrading

To upgrade your Kubernetes clusters, simply pull down the latest Terraform configs from our repository and run terraform apply. Terraform will then upgrade each node in your cluster one by one and shouldn’t cause any interruption in service. We generally recommend upgrading to the latest point release for your current minor version before upgrading the minor version. And if you’re behind on minor versions, upgrade each minor version in turn - don’t skip minor versions!

If your Kubernetes cluster is managed by us, then you don’t have to do anything and we’ll arrange the upgrade for you.

containerd 1.0 support comes to an end

This is the last version of Kubernetes that supports containerd 1.x so you’ll want to be thinking about upgrading all your nodes. Aiming for the upcoming Ubuntu LTS 26.04 release will get you that, or consider upgrading containerd manually.

k3s: Lightweight Kubernetes

We’ve also been playing with the trimmed down lightweight Kubernetes project, k3s. Our cloud controller works perfectly fine on k3s and we’re working on some kubernetes manifests to build k3s clusters - coming soon!

Get started

You can sign up for Brightbox in just a couple of minutes and get a £50 free credit to play with Kubernetes.

We’ve got a simple guide to deploying a Kubernetes cluster pre-configured with our cloud controller using Terraform.

Managed Kubernetes

If you’re looking for a UK-based fully-managed Kubernetes solution, drop us a line.

Orbit Object Storage updates

2025-01-14T00:00:00Z

Orbit is our highly available and durable object storage service. It’s at the centre of so many of our services at Brightbox: all Cloud Server and Cloud SQL snapshots, all our managed customer logs and backups, and of course it is used directly by customers via its HTTP APIs to store various assets.

Orbit is based on the excellent OpenStack Swift project and last year we rolled out some updates that add new features. We also added and upgraded a lot of Orbit hardware that improved performance too.

Performance

We moved all container services to SSD which improved latency for most metadata operations considerably, as well as allowing us to improve consistency with faster replication updates.

We were able to increase throughput on the object HDD storage systems and now objects uploads are faster: in particular, larger object uploads are 1.65x faster!

And due to some cache tuning, we’ve also improved read times for “hot” objects.

We’ve got more networking improvements planned for this year which should get us another boost too. We’ll keep you posted.

S3 Compatibility

The Swift API is well supported but we know that the S3 API has become a strong defacto standard for storage systems over the last few years, particularly in the Kubernetes world. Orbit’s S3 compatibility has now been expanded and supports more S3 features and with improved S3 performance.

Temporary URL improvements

Temporary URLs allows the creation of a special URL that points to a specific object and allows reads and/or writes to it for a limited amount of time without requiring authentication credentials. This is perfect for when you want to control access to objects via a separate application but still want Orbit to handle the serving of the objects. And you can now limit access to a temporary URL by IP address.

And more…

And as ever, Orbit runs on our entirely UK owned and operated infrastructure and stores 3 copies of each object on separate storage devices. Data is encrypted in-flight and at-rest on disk.

You can read and write data to Orbit containers using the standard OpenStack Swift HTTP API, any number of libraries (Ruby, Node, PHP etc), the Swift CLI tool or even our simple SFTP service. Anything that can use OpenStack Swift can use Orbit! We’ve got guides for many tools, such as for the Restic backup tool and Rclone.

Try Orbit on Brightbox

You can sign up for Brightbox in just a couple of minutes and use your £50 free credit to play with Orbit. Give it a go!

PostgreSQL 17 now available in Cloud SQL

2024-10-10T00:00:00Z

Today we’re announcing support for version 17 of PostgreSQL in Cloud SQL.

PostgreSQL 17 contains a number of new features and enhancements, including:

New memory management system for VACUUM that consumes up to 20x less memory
New SQL/JSON capabilities, including a new JSON_TABLE() function which converts JSON data into a standard PostgreSQL table
Various query performance improvements, including increased write throughput under high concurrency
Several enhancements to logical replication
New pg_maintain predefined role, which gives users permission to perform maintenance operations
pg_basebackup now supports incremental backups

Check out the official release notes for a complete list of updates and details.

If you’re new to Brightbox, Cloud SQL is our simple database-as-a-service which enables you to effortlessly create high performance PostgreSQL and MySQL database servers with automated backups and security updates as well as the ability to instantly increase RAM, CPU and storage resources when required.

Cloud SQL features PostgreSQL support back to version 12, and still allow building instances with older deprecated versions back to version 9.5 if required.

Try PostgreSQL 17 on Brightbox for free!

If you’re an existing customer you can start creating Postgres 17 instances right away.

If you’re not yet a customer you can create a Brightbox account in just a couple of minutes and get a £50 free credit to give Cloud SQL a try.

Sharing secrets with SSH keys

2024-09-18T00:00:00Z

As part of our managed ops services we often need to share sensitive information such as passwords and keys with customers. GPG is commonly used for this kind of thing, but if our customers aren’t already used to PGP it’s a bit of a pain - particularly with all the key swapping, signing and trust settings you often need to manage.

However, most of our customers already have an SSH keypair that they use to access their Brightbox servers and if we’re managing their servers we already know their public keys. Can we use a customer’s SSH keys to encrypt messages for them? Yes we can! And a tool called age makes this easy - much eaiser than GPG.

First, install age. It’s available natively for most modern Linux distros, BSDs, Windows and macOS so it should only take a minute.

Then to encrypt a message with an SSH public key run age with the --recipients-file argument (and use CTRL+D to finish the message of course):

$ age --recipients-file ~/keys/customer-ssh-key.pub --encrypt --armor

Hello world

-----BEGIN AGE ENCRYPTED FILE-----
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IHNzaC1lZDI1NTE5IHlMSFZYQSBjVkZC
YlRKcG1JcG8xTkFjb2pzOHdEVUoyaWFhWTNTaE1tZDNhd0VhQkQwCm1VMkFzd01H
QWYxREhlQXF6TTJGU3ZrMGhMTDFKb2ZhU2JTeUhLdnlhcEEKLS0tIDM5UWVDUWJz
WTZYZkZpTTVQcWE0UkM4aTRMNnIrUzJUMHVKVFVRWGorVXMKN4uVA5nSZP0uAWlH
xjHVbrO42sNUe3jiI+rHKP+epsWvtRl5rMlVfTVxDzUc
-----END AGE ENCRYPTED FILE-----

You can then paste the output in an email or a text chat session.

And then for them to decrypt the message with their SSH private key:

$ age --decrypt -i .ssh/my-ssh-key.key

-----BEGIN AGE ENCRYPTED FILE-----
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IHNzaC1lZDI1NTE5IHlMSFZYQSBjVkZC
YlRKcG1JcG8xTkFjb2pzOHdEVUoyaWFhWTNTaE1tZDNhd0VhQkQwCm1VMkFzd01H
QWYxREhlQXF6TTJGU3ZrMGhMTDFKb2ZhU2JTeUhLdnlhcEEKLS0tIDM5UWVDUWJz
WTZYZkZpTTVQcWE0UkM4aTRMNnIrUzJUMHVKVFVRWGorVXMKN4uVA5nSZP0uAWlH
xjHVbrO42sNUe3jiI+rHKP+epsWvtRl5rMlVfTVxDzUc
-----END AGE ENCRYPTED FILE-----

Hello world

Of course age isn’t limited to short text messages and will encrypt large files too, just don’t use the --armor option it’ll generate a more compact binary output.

Integration with GitHub

All GitHub users have an SSH key and if you know somebody’s GitHub username you can encrypt things for them with age:

$ curl https://github.com/johnl.keys | age --recipients-file - --armor message.txt

Age has its own keys too

If you prefer to use separate keys, age does have its own key format and keys can be generated with the age-keygen tool. age keys are pretty neat and easy to share:

$ age-keygen 

# created: 2024-09-18T10:53:06+01:00
# public key: age1texszzr0vlrfvjug5gd4dgkla39j2swchvrgdmd8qg50wafnsqqs8ygqhp
AGE-SECRET-KEY-1YJ23M3V0LH2AXGHHNTE8GLPWAAP3HEFHT9Y6LYQRCWDP8VHXWC4Q3DJ5A6

Passwords instead of keys

You can also just forego the use of public and private keys and use symmetric key encryption and choose a password when encrypting. If you don’t provide one, age will randomly generate a password that you can easily read out to someone in-person or over the phone:

$ age --encrypt --passphrase --armor

Enter passphrase (leave empty to autogenerate a secure one):

age: using autogenerated passphrase "object-feature-make-rather-add-coil-project-february-easily-goose"

Hello World

-----BEGIN AGE ENCRYPTED FILE-----
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IHNjcnlwdCByektjYXdid0M4MytRUmI1
U3lJYm13IDE4Ci83d1RqRUJ3S2Q1TkZpNndFZUhRVUVGcERpNUxCR3V4dStVOTMv
TC9xREkKLS0tIE44TG5tUm9SWXd5Z05jUDlVMXBJQjl5L29VcXlvOFJlai9xU0pV
Q1FVUjgKeSW+1umEBcBn8BZ983gdf3nG4yuzuJz2Vt6VluIEIbFBiDI2aDVEu8uW
jC+C
-----END AGE ENCRYPTED FILE-----

And you can use the passhrase encryption to secure your age keys on-disk - age recognises this and will prompt for the passphrase.

Managing secrets in git repositories

age can be used to encrypt files in git repositories using a tool called SOPS. We use this for encrypting secrets in OpenTofu/Terraform and Kubernetes manifests. We’ll go into more detail on how to use that in a future blog post.

Limitations

SSH keys are usually used only for authentication, so people may not treat them quite the same as a real encryption key - they may be more likely to share them, or otherwise treat them as revokable.

And SSH keys on hardware such as YubiKeys can’t be used to decrypt files.

But otherwise, using SSH keys with age is a very convenient way of occasionally sharing secrets.

Flatcar Container Linux official images now available

2024-04-11T00:00:00Z

Flatcar Container Linux is a minimal, container-optimised Linux distribution, which is a direct descendent and spiritual successor of CoreOS Container Linux, which was discontinued and replaced by Fedora CoreOS in 2020.

Flatcar provides a drop-in replacement and plans to continue following the philosophy pioneered by CoreOS, delivering a fully open source, minimal-footprint, secure by default and always up-to-date Linux distribution for running containers at scale.

Recently, Flatcar began building and testing images for deployment on Brightbox and I’m pleased to announce that we’re now automatically importing the latest Stable, LTS and Beta releases as a result.

The images are available now in our image library and integrate with our Amazon EC2-compatible metadata service, so they install your ssh keys automatically on boot and you can ssh straight in as the core user.

Like all of our other official linux distro images, they’re provided completely unmodified from the upstream source, so you can be sure there are no hidden surprises. If your systems work on the upstream images, they’ll work on ours.

We’ve written a guide to help you get started and you should be able to get a new Flatcar server with a basic configuration up and running in a few minutes.

Check out Flatcar’s documentation for more details on the available features and more advanced configuration topics.

If there are other well-maintained linux distros that you’d like to see us offer in the cloud server image library, do let us know.

Of course, if you’re not yet a Brightbox customer, you can create an account in just 2 minutes and get £50 free trial credit to try the new images out.

Resizing Cloud SQL Database Instances

2024-04-09T00:00:00Z

Last year we introduced the ability to resize Cloud Servers, which makes it really quick and easy to increase RAM/CPU and SSD storage for your cloud servers.

I’m really pleased to say that we’ve now added the ability to resize Cloud SQL instances too!

Cloud SQL is our database-as-a-service which enables you to effortlessly create high performance MySQL and PostgreSQL database servers with automated backups and security updates.

So now if you need to add more RAM, CPU and SSD storage to your Cloud SQL instance you can simply choose a larger database type and hit “Save”. The change will happen instantly, but a restart is needed for the database engine to make full use of the new resources. A restart is automatically scheduled for your next maintenance window or you can choose to manually restart at your own convenience using the new Restart action.

We’ve written a simple guide to guide to resizing Cloud SQL instances so do check that out and as always if you have any questions or feedback let us know and we’ll be happy to help.

If you’re an existing customer you can start using the new resize feature straightaway. If you’re not yet a customer, you can get signed up in 2 minutes and try out Brightbox with a free £50 trial credit.

Exploring OpenToFu: A Fork of Terraform

2024-02-02T00:00:00Z

In the world of infrastructure as code (IaC), Terraform has been a stalwart companion for nearly a decade. However, recent changes in its licensing have left many in the community seeking alternatives. Enter OpenToFu – a fork of Terraform that emerged as a result of community-driven development.

OpenToFu aims to be backward compatible with Terraform, making the transition for existing users smooth. The familiar syntax, provider ecosystem, and module structure are all present, ensuring that your existing infrastructure code works as expected.

You’ll be pleased to know that the existing Brightbox terraform driver works flawlessly with the OpenToFu fork, giving Brightbox users the choice as to which tool to use.

Installation

OpenToFu is straightforward to install in various ways, and they provide a convenient install script that takes care of the process for you:

# Download the installer script:
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh -o install-opentofu.sh

# Give it execution permissions:
chmod +x install-opentofu.sh

# Please inspect the downloaded script

# Run the installer:
./install-opentofu.sh --install-method deb

Initialising the Manifests

As with Terraform, OpenToFu needs to install its support modules before it can run a plan. The command is very familiar:

$ tofu init

Initializing the backend...

Initializing provider plugins...
- Finding brightbox/brightbox versions matching "~> 3.0"...
- Installing brightbox/brightbox v3.4.3...
- Installed brightbox/brightbox v3.4.3 (signed, key ID 86A01C78D276AC7C)

Providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://opentofu.org/docs/cli/plugins/signing/

OpenTofu has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that OpenTofu can guarantee to make the same selections by default when
you run "tofu init" in the future.

OpenTofu has been successfully initialized!

You may now begin working with OpenTofu. Try running "tofu plan" to see
any changes that are required for your infrastructure. All OpenTofu commands
should now work.

If you ever set or change modules or backend configuration for OpenTofu,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

And that’s it. Swap terraform for tofu and you’re good to go. If you need any further information the OpenTofu website has a good documentation section

Solving the Dining Philosophers Problem with systemd - Part 3

2024-01-17T00:00:00Z

This is part 3 of a 3-part series where we solve the Dining Philosophers concurrency problem using just UNIX, systemd and some bash scripting!

In part 2 we created multiple philosophers using separate user ids, got them to take their seat in the dining room and even pick up their initial forks¹.

Now we need to implement the core part of the dining philosopher’s problem - the conflict resolution layer - and that means we need an appropriate algorithm.

We’ll be using a variant of the Chandry/Misra “hygiene” solution. Our initial setup of the forks ensures that the graph between the philosopher nodes and the fork edges is acyclical. Each of the transformations from now on will maintain that acyclical form, avoiding a deadlock.

When a philosopher gets hungry (i.e. reaches the systemd hungry target), they check if they have both forks. If not, they need to ask their neighbouring philosophers for a fork.

For each request for a fork they receive, they make a simple decision:

if they are thinking and they have the fork, they delete the fork and offer the fork to their neighbour by sending them a message
otherwise, they ignore the request

For each fork offer received from a neighbour, a fork is created. Forks can only be acquired as a result of these offers and thereby with the permission of the neighbour. This both maintains the acyclical nature of the fork graph and avoids starvation (systemically and metaphorically).

Once a philosopher has two forks they enter the eating state and set a time in the future when they will start thinking again.

Before they enter the thinking state, the forks are deleted and they are transferred to neighbours by sending them a fork offer message.

Now to implement this in the Unix Programming Environment.

The veritable sendmail and mailutils

The philosophers will send messages to each other using Unix mail, provided by the sendmail daemon. This is how users communicated with each other on multi-user Unix machines back in the good old days before social media.

The sendmail daemon has a deserved reputation for being a devil to configure properly. Fortunately, we can use it out of the box because modern cloud servers are encased in system-level firewalls that prevent external access.

We’ll use sendmail’s rather useful ability to pipe received messages into a script. By placing a mail processor command in the .forward file for each philosopher we create a simple, but effective, event-driven message system.

The mail processor uses a bit of sed magic to strip out the subject and isolate who the messages are from. Then for each pair, it invokes a mail task and logs any output to the local0 syslog facility with a ‘mail-tasks’ identifier so we can isolate them later.

#!/bin/sh
set -e
sed -n '/^From: /s/^From: .* <\(.*\)@.*$/\1/p
/^Subject: /s/^Subject: \(.*\)$/"\1"/p' |
    xargs -r -n 2 -- /usr/local/bin/mail-tasks |
    logger -p local0.info -t mail-tasks

Sending messages is a simple wrapper around the standard mail command that gives us the ‘fork-request’ and ‘fork-response’ messages we need. First the ‘fork-request’

#!/bin/sh
# fork-request
if [ "$#" -eq 0 ]
then
    echo "Usage: ${0##*/} name..."
    exit 64
fi
for word
do
    echo "Asking ${word} for the shared fork"
    mail -E'unset nullbodymsg' -s 'Fork Request' "${word}" < /dev/null
done

and the ‘fork-response’:

#!/bin/sh
# fork-response
if [ "$#" -eq 0 ]
then
    echo "Usage: ${0##*/} name..."
    exit 64
fi
for word
do
    echo "Sending ${word} our shared fork"
    mail -E'unset nullbodymsg' -s 'Fork Response' "${word}" < /dev/null
done

Update the eating service

The first update we make is to the eating-food service. When it starts, we still run the consumption script but now we want to run the fork-release script when the service shuts down. This nicely wraps the eating timer without introducing any further systemd units.

[Unit]
Description=Eating Food
ConditionPathIsDirectory=/home/share/dining-room
PartOf=eating.target

[Service]
Type=oneshot
SyslogFacility=local0
RemainAfterExit=yes
ExecStart=/usr/local/bin/consumption
# Send forks to neighbours after eating
ExecStop=/usr/local/bin/fork-release

We add the RemainAfterExit setting to the unit so that it enters the active state and will be shut down (running the ExecStop command) when the timer triggers the transition to the thinking target.

The fork release script is very simple:

# fork-release
#!/bin/sh
set -e

echo "Releasing forks"
rm -f ${HOME}/forks/*
echo "Transferring forks"
neighbours | xargs -r response-fork

and it neatly cleans up the spare fork that was left over from the initialisation process, once that philosopher has completed their first meal.

The neighbours script finds out who is in the seats on either side of a philosopher, including from the head to the foot of the table. It does this using a count function that determines the number of seats dynamically within the shell.

# count fileglob
count() {
    case ${1##*/} in
        \*)
            echo 0
            ;;
        *)
            echo $#
            ;;
    esac
}

seat=$(my-dining-seat)
max=$(count ${diningroom}/seats/*)
max=$((max + base))
right_index=$((seat + 1))
if [ "${right_index}" -gt "${max}" ]
then
    right_index=$((base + 1))
fi
left_index=$((seat - 1))
if [ "${left_index}" -eq "${base}" ]
then
    left_index=${max}
fi

The fork check

The hungry timer is replaced by a fork-check service. The unit has a few interesting features:

[Unit]
Description=Fork Check
ConditionPathIsDirectory=/home/share/dining-room
CollectMode=inactive-or-failed
OnSuccess=eating.target
OnFailure=fork-request.service
After=hungry.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/fork-check
SyslogFacility=local0

This is a branch unit that triggers other processes depending on whether the check succeeds or fails. We update CollectMode so systemd garbage collects the unit even if it has failed.

When the check succeeds it transitions to the eating target, and on failure it requests the forks from neighbours.

fork-check looks for two forks in the philosopher’s fork area and returns a temporary failure if they are not there.

diningroom=/home/share/dining-room
forkarea=${HOME}/forks
base=10

lfork=$(my-dining-seat)
max=$(count ${diningroom}/seats/*)
max=$((max + base))
rfork=$((lfork + 1))
if [ "${rfork}" -gt "${max}" ]
then
    rfork=$((base + 1))
fi

if [ -w "${forkarea}/${lfork}" ] &&
   [ -w "${forkarea}/${rfork}" ]
then
    echo "I have two forks"
    exit 0
fi
# Return EX_TEMPFAIL
exit 75

The core of fork-request asks a neighbour for the fork if we don’t have it by sending them a request message:

# ask_for_fork fork_file fork_num neighbour_name
ask_for_fork() {
    if [ -w "${1}" ]
    then
        echo "I already have fork #${2}"
    else
        echo "I don't have fork #${2}"
        request-fork "${3}"
    fi
}

Processing the mail tasks

The mail-tasks script uses different branches based on the mail subject to manage specific types of messages. This allows for easy extension by assigning the task of handling a particular message to a specific script. Adding new message types in the future simply involves adding another branch in the case statement.

#!/bin/sh
set -e

if [ "$#" -ne 2 ]
then
    echo "Usage: ${0##*/} username subject"
    exit 64
fi

case "$2" in
Fork\ Request)
    exec mail-task-fork-request "$1"
    ;;
Fork\ Response)
    exec mail-task-fork-response "$1"
    ;;
*)
    echo "Unknown mail request ${2} from ${1}"
    echo "Discarding mail"
    exit 0
esac

Each message handler is a self-contained script for each particular task. A fork request is rejected if the philosopher is hungry or eating. We ask systemd what state it is in a manner that is as atomic as possible. If the philosopher is hungry, do a backup check to see if they have two forks and can start eating:

echo "Received fork request from $1"
# Try to be as atomic as possible
if systemctl --user --quiet is-active eating.target hungry.target
then
    if systemctl --user --quiet is-active hungry.target
    then
        echo "while hungry."
        echo "I have priority"
        try_to_eat
        exit 0
    else
        echo "while eating."
        echo "I'll respond when I've finished eating."
        exit 0
    fi
fi

otherwise, we’ll remove the fork and send it to their neighbour, after a last-second check that the philosopher is still thinking.

remove_fork() {
    if [ -w "${HOME}/forks/$1" ]
    then
        # Final check we're in the right state before removing forks
        if systemctl --user --quiet is-active eating.target hungry.target
        then
            echo "Transistioned away from thinking while processing"
            echo "Ignoring request"
            exit 0
        else
            rm "${HOME}/forks/$1"
            echo "Released fork #$1"
        fi
    else
        echo "I don't have fork #$1"
        echo "Ignoring request"
        exit 0
    fi
}

The fork response is a little more straightforward. First, grab the fork that has been sent through. Then, if the philosopher is hungry, see if they have both forks and can start eating:

echo "Received fork response from $1"
if [ "${other}" -eq "${left_index}" ]
then
    grab_fork "${seat}"
elif [ "${other}" -eq "${right_index}" ]
then
    grab_fork "${right_index}"
else
    echo "Fork Response error"
    echo "Unexpected seat ${other} for $1"
    echo "I'm seat ${seat}, left is ${left_index}, right is ${right_index}"
    echo "Discarding mail"
    exit 0
fi
if systemctl --user --quiet is-active hungry.target
then
        try_to_eat
fi
exit 0

Installation

Now we’re ready to run the full simulation. To try it yourself, install the code from the repo. Log in as an admin user on an Ubuntu server, clone the repo and run the setup script

ubuntu@srv-2q8eh:~$ git clone --depth 1 --branch part-3 git@github.com:brightbox/systemd-dining.git
Cloning into 'systemd-dining'...
...
ubuntu@srv-2q8eh:~$ cd systemd-dining/
ubuntu@srv-2q8eh:~/systemd-dining$ sudo ./setup.sh
Adding required packages
...
Installing simulation

Run the simulation

Create the philosophers:

ubuntu@srv-2q8eh:~/systemd-dining$ xargs -L 1 sudo /usr/local/sbin/create_philosopher < philosophers

Open the dining room:

ubuntu@srv-5o1ic:~/systemd-dining$ sudo open_dining_room

Stop the simulation

Close the dining room:

ubuntu@srv-5o1ic:~/systemd-dining$ sudo close_dining_room

Remove the philosophers:

ubuntu@srv-2q8eh:~/systemd-dining$ awk '{print $1}' philosophers | xargs sudo /usr/local/sbin/remove_philosopher

Interrogate the simulation

While running, all of the Unix process tools are available. Of particular use is the journalctl command and the convenience script npcjournal which allows you to look at a single philosopher by user name.

ubuntu@srv-4mujm:~$ npcjournal kant
Nov 27 18:49:31 fork-release[1531112]: Sending nietzsche our shared fork
Nov 27 18:49:31 contemplation[1531145]: Currently contemplating the perspective that time and space are not
Nov 27 18:49:31 contemplation[1531145]: external conditions but subjective forms of our intuition.
Nov 27 18:49:46 hunger[1531542]: Getting hungry...

Or follow their activity:

ubuntu@srv-4mujm:~$ npcjournal -f hegel
Nov 29 12:07:41 consumption[802905]: Eating...
Nov 29 12:07:49 mail-tasks[803067]: Received fork request from socrates
Nov 29 12:07:49 mail-tasks[803067]: while eating.
Nov 29 12:07:49 mail-tasks[803067]: I'll respond when I've finished eating.
Nov 29 12:07:52 fork-release[803154]: Releasing forks
Nov 29 12:07:52 fork-release[803154]: Transferring forks
Nov 29 12:07:52 fork-release[803163]: Sending socrates our shared fork
Nov 29 12:07:53 fork-release[803163]: Sending mill our shared fork

Perhaps you want to see what a philosopher has been thinking about:

ubuntu@srv-4mujm:~$ npcjournal --since=today --identifier=contemplation wittgenstein
Nov 29 00:01:14 contemplation[3981849]: Currently contemplating the view that philosophy is not a theory but
Nov 29 00:01:14 contemplation[3981849]: an activity, an approach to language that transforms our conceptual
Nov 29 00:01:14 contemplation[3981849]: framework.
Nov 29 00:02:11 contemplation[3983193]: Currently contemplating the belief that philosophy should be concerned
Nov 29 00:02:11 contemplation[3983193]: with clarifying language rather than solving metaphysical puzzles.
Nov 29 00:03:08 contemplation[3984372]: Currently contemplating the notion that the structure of language reflects
Nov 29 00:03:08 contemplation[3984372]: the structure of reality, and philosophical problems are linguistic
Nov 29 00:03:08 contemplation[3984372]: in nature.

Or maybe what messages have been sent by the mail system between the philosophers:

ubuntu@srv-4mujm:~$ journalctl --since=today --facility=mail
Nov 29 00:00:03 srv-4mujm sendmail[3980626]: 3AT003YC3980626: from=plato@srv-4mujm.gb1.brightbox.com, size=113, >
Nov 29 00:00:03 srv-4mujm sm-mta[3980627]: 3AT003KE3980627: from=<plato@srv-4mujm.gb1.brightbox.com>, size=399, >
Nov 29 00:00:03 srv-4mujm sendmail[3980626]: 3AT003YC3980626: to=schlegel, ctladdr=plato@srv-4mujm.gb1.brightbox>
Nov 29 00:00:03 srv-4mujm sendmail[3980635]: 3AT003BX3980635: from=plato@srv-4mujm.gb1.brightbox.com, size=113, >
Nov 29 00:00:03 srv-4mujm sm-mta[3980628]: 3AT003KE3980627: to=|/usr/local/bin/mail-processor, ctladdr=<schlegel>
Nov 29 00:00:03 srv-4mujm sm-mta[3980646]: 3AT003W33980646: from=<plato@srv-4mujm.gb1.brightbox.com>, size=399, >
Nov 29 00:00:03 srv-4mujm sendmail[3980635]: 3AT003BX3980635: to=socrates, ctladdr=plato@srv-4mujm.gb1.brightbox>
Nov 29 00:00:03 srv-4mujm sm-mta[3980649]: 3AT003W33980646: to=|/usr/local/bin/mail-processor, ctladdr=<socrates>o

And if you can’t remember their name, we can look that up:

ubuntu@srv-4mujm:~$ finger -p wittgenstein
Login: wittgenstein   			Name: Ludwig Wittgenstein
Directory: /home/wittgenstein       	Shell: /bin/bash
Last login Sun Nov 26 08:12 (UTC) on pts/2
Mail forwarded to |/usr/local/bin/mail-processor
No mail.

Gathering the statistics from the journal for how long each philosopher stays hungry is left as an exercise for the reader. Let me know how you get on.

Epilogue

And there we have it, a short run around some of the older, esoteric features of the Unix Programming Environment combined with some of the newer systemd features. With these tools, we have built a Dining Philosophers solution using little more than a few shell scripts. Not a compiler in sight.

If you come up with any potential improvements to the system, please drop an issue or a pull request on the repo. I’m sure it can be improved in many ways.

Again, we mean the eating utensils, not child processes. ↩

Solving the Dining Philosophers Problem with systemd - Part 2

2024-01-11T00:00:00Z

This is part 2 of a 3-part series where we solve the Dining Philosophers concurrency problem using just UNIX, systemd and some bash scripting!

In part 1, we created a simple state machine with systemd units and watched it do its thing by interrogating the journal. For part 2, we’ll use the multi-user capabilities of Linux and create a set of philosophers running independent processes.

Every process in Linux runs with a user identifier, plus a primary group and a list of secondary groups the user identifier is part of. Access control to resources within Linux is managed via this set of identifiers.

Creating a philosopher is a matter of adding a user ID, a group ID, and adding the user ID to a secondary group, philosophers, which we’ll use to control access to shared resources like dining seats and forks¹.

$ sudo -s
$ addgroup philosophers
$ adduser --disabled-password --shell /bin/bash --gecos "Immanuel Kant" kant 
Adding user `kant' ...
Adding new group `kant' (1002) ...
Adding new user `kant' (1001) with group `kant' ...
Creating home directory `/home/kant' ...
Copying files from `/etc/skel' ..
$ adduser kant philosophers
Adding user `kant' to group `philosophers' ...
Adding user kant to group philosophers
Done.
$ loginctl enable-linger kant

We can see the philosopher’s details using the finger command:

$ finger kant
Login: kant           			Name: Immanuel Kant
Directory: /home/kant               	Shell: /bin/bash
Never logged in.
No mail.
No Plan.

Now let’s add the units we created in part 1 to /etc/systemd/user, so they are available to everybody, and then we can start the new user thinking

$ sudo machinectl shell kant@ /usr/bin/systemctl --user start thinking.target
Connected to the local host. Press ^] three times within 1s to exit session.

Connection to the local host terminated.

With the system running, we can look at what the philosopher has done by interrogating the journal.

$ journalctl _UID=$(id -u kant)
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Queued start job for default target Main User Target.
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Created slice User Application Slice.
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Reached target Paths.
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Reached target Timers.
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Starting D-Bus User Message Bus Socket...
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Listening on GnuPG network certificate management daemon.
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Listening on GnuPG cryptographic agent and passphrase cache.
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Listening on debconf communication socket.
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Listening on REST API socket for snapd user session agent.
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Listening on D-Bus User Message Bus Socket.
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Reached target Sockets.
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Reached target Basic System.
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Reached target Main User Target.
Nov 24 07:09:21 srv-hy7z5 systemd[2995]: Startup finished in 142ms.
Nov 24 07:10:07 srv-hy7z5 systemd[2995]: Started Thinking Period.
Nov 24 07:10:07 srv-hy7z5 systemd[2995]: Starting Contemplation...
Nov 24 07:10:07 srv-hy7z5 contemplation[3018]: Currently contemplating the enigmatic nature of reality: the existential
Nov 24 07:10:07 srv-hy7z5 contemplation[3018]: grasp for an elusive fork, the categorical imperative of simulated
Nov 24 07:10:07 srv-hy7z5 contemplation[3018]: existence, and the irony in questioning the true essence of the held
Nov 24 07:10:07 srv-hy7z5 contemplation[3018]: object.
Nov 24 07:10:07 srv-hy7z5 systemd[2995]: Finished Contemplation.
Nov 24 07:10:07 srv-hy7z5 systemd[2995]: Reached target Thinking....

To stop the process, we can just get rid of the user

$ sudo -s
$ loginctl disable-linger kant
$ deluser kant philosophers
Removing user `kant' from group `philosophers' ...
Done.
$ deluser --remove-home kant
Looking for files to backup/remove ...
Removing user `kant' ...
Warning: group `kant' has no more members.
Done.

Customising the philosophers

Of course, we don’t want to create philosophers one at a time and manually start each one. We want the computer to take care of that. Plus we want them to think about different things. Otherwise, what’s the point of each of them having a unique identity?

To give them some individuality, we can use the .project file in their home directories and store the things we want the philosopher to think about there. Then we alter the contemplation script to select a random line from .project with the shuf command.

# /usr/local/bin/contemplation
#!/bin/sh
set -e

default_thought="the enigmatic nature of reality: the existential grasp
for an elusive fork, the categorical imperative of simulated existence,
and the irony in questioning the true essence of the held object."
{
    printf '%s' 'Currently contemplating '
    if [ -e "${HOME}/.project" ]
    then
        shuf -n 1 "${HOME}/.project"
    else
        printf '%s\n' "${default_thought}"
    fi
} | fmt
exit 0

Starting the simulation

Now we’re ready to create multiple philosophers each with a list of things to think about. To start the simulation, we need them to take their seat at the dining table and prepare to do battle over the forks when they get hungry.

We can signal that the simulation should start by creating a dining-room directory in a shared area. Once systemd sees this directory, the philosopher can run a script to select their seat.

Selecting seats is straightforward: we set the setgid bit on a seat directory in dining-room and make it writable by the group philosophers. This stops philosophers from overwriting each other’s files. As each philosopher accesses the dining room, they take the next seat available by trying to create a file in the shared area with the seat number and incrementing until they succeed.

echo "The Dining Room is open. Looking for a seat."
seat=${head}
until touch "${diningroom}/seats/${seat}" 2>/dev/null
do
    seat=$((seat+1))
done
echo "I have seat #${seat}"

Forks are allocated relative to the seat obtained. Each philosopher creates a file to represent the fork on their right-hand side, which is numbered one more than their seat number. The forks are created and maintained in the philosopher’s home directory.

grab_fork() {
    touch "${HOME}/forks/$1"
    echo "Acquired fork #$1"
}
...
echo "Creating my fork store"
rm -rf "${HOME}/forks"
mkdir "${HOME}/forks"
grab_fork $((seat+1))

The head of the table, the philosopher in the lowest seat position, also gets the fork on their left-hand side.

if [ "${seat}" -eq "${head}" ]
then
    grab_fork ${head}
fi

Before starting, the philosopher waits until all others have taken their seats.

echo "Waiting for everybody to take their seats"
fsnotifywait -q -q -e close_write -t "${WAIT_FOR_READY_SECS}" -m "${diningroom}/seats" || [ "$?" -eq 2 ]

echo "Starting..."

Those still awake at this point in the piece will have noticed that the philosopher at the foot of the table appears to have a fork that cannot be used or acquired by anybody else. The nature of this fork and whether it exists if it cannot be acquired is precisely what the philosophers contemplate when they are not thinking about something else. We deal with it in part 3.

A path systemd unit and the associated service unit allow us to start this selection process when the dining room is available.

# select-seat.path
[Unit]
Description=Watch Dining Room

[Path]
PathModified=/home/share/dining-room

[Install]
WantedBy=default.target

And the service:

# select-seat.service
[Unit]
Description=Seat Selection
ConditionPathIsDirectory=/home/share/dining-room
Conflicts=hungry.target eating.target
OnSuccess=thinking.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/select-seat
SyslogFacility=local0

[Install]
WantedBy=default.target

Here, we use an OnSuccess entry to trigger the start of the simulation by starting the thinking target after the select seat service has completed, and a Condition on the service to make sure it doesn’t try to start if the dining room is missing.

The path entry stays in place continuously so that it triggers whenever the dining room is created.

To get the user-level systemd to activate these units automatically, we need to tie it into the default target by having the relevant symbolic links in the systemd area. If we add these to the home directory skeleton then each new user will get those links straight away and systemd will read them.

$ sudo mkdir -p /etc/skel/.config/systemd/user/default.target.wants
$ sudo ln -sf /etc/systemd/user/select-seat.path \
    /etc/systemd/user/select-seat.service \
    /etc/skel/.config/systemd/user/default.target.wants

This is essentially what systemctl --user enable <unit> usually does.

Create the users and off we go

Now we’re ready to run the simulation.

First, we need a philosophers file containing the details of the users²:

kant "Immanuel Kant" "a real pissant" projects/kant
heidegger "Martin Heidegger" "boozy beggar" projects/heidegger
hegel "Wilhelm Friedrich Hegel" "lightweight" projects/hegel
hume "David Hume" "out-consumer" projects/hume
schlegel "Friedrich Schlegel" "schloshed" projects/schlegel
wittgenstein "Ludwig Wittgenstein" "beery swine" projects/wittgenstein
nietzsche "Friedrich Nietzsche" "teacher of the raising of the wrist" projects/nietzsche
socrates "Socrates" "permanently pissed" projects/socrates
mill "John Stuart Mill" "on half a pint of shandy was particularly ill" projects/mill
plato "Plato" "half a crate of whisky every day" projects/plato
aristotle "Aristotle" "bugger for the bottle" projects/aristotle
hobbes "Thomas Hobbes" "fond of his dram" projects/hobbes
descartes "Rene Descartes" "drunken fart" projects/descartes

along with all the setup scripts, project files and systemd units. Fortunately, I’ve done that for you and you can just clone the git repo onto a new Ubuntu LTS server:

$ git clone git@github.com:brightbox/systemd-dining.git

and switch to the part 2 tag:

$ git switch part-2

then run the setup to install the tools:

$ cd system-dining
$ sudo ./setup.sh

Once the files are in place we can create the philiosophers:

$ xargs -L 1 sudo /usr/local/sbin/create_philosopher < philosophers

and then open the dining room to start the simulation:

$ sudo open_dining_room

Then we can sit back and watch the simulation unfold by tailing the journal:

$ journalctl -f
Nov 24 12:13:43 srv-hy7z5 systemd[5124]: Finished Seat Selection.
Nov 24 12:13:43 srv-hy7z5 systemd[4635]: Finished Seat Selection.
Nov 24 12:13:43 srv-hy7z5 systemd[5124]: select-seat.service: Triggering OnSuccess= dependencies.
Nov 24 12:13:43 srv-hy7z5 systemd[4635]: select-seat.service: Triggering OnSuccess= dependencies.
Nov 24 12:13:43 srv-hy7z5 systemd[4635]: Started Thinking Period.
Nov 24 12:13:43 srv-hy7z5 contemplation[5313]: Currently contemplating the belief that the value of actions is determined
Nov 24 12:13:43 srv-hy7z5 contemplation[5313]: by their contribution to individual self-interest and preservation.
Nov 24 12:13:43 srv-hy7z5 systemd[5124]: Started Thinking Period.
Nov 24 12:13:43 srv-hy7z5 systemd[5058]: Finished Contemplation.
Nov 24 12:13:43 srv-hy7z5 systemd[5058]: Reached target Thinking....
Nov 24 12:13:43 srv-hy7z5 systemd[4635]: Starting Contemplation...
Nov 24 12:13:43 srv-hy7z5 systemd[5124]: Starting Contemplation...
Nov 24 12:13:43 srv-hy7z5 contemplation[5317]: Currently contemplating the understanding that what can be said at all
Nov 24 12:13:43 srv-hy7z5 contemplation[5317]: can be said clearly, and what we cannot talk about, we must pass over
Nov 24 12:13:43 srv-hy7z5 contemplation[5317]: in silence.
Nov 24 12:13:43 srv-hy7z5 systemd[4635]: Finished Contemplation.
Nov 24 12:13:43 srv-hy7z5 systemd[4635]: Reached target Thinking....
Nov 24 12:13:43 srv-hy7z5 contemplation[5319]: Currently contemplating the certainty that I exist as a thinking being:
Nov 24 12:13:43 srv-hy7z5 contemplation[5319]: 'Cogito, ergo sum' - I think, therefore I am.
Nov 24 12:13:43 srv-hy7z5 systemd[5124]: Finished Contemplation.
Nov 24 12:13:43 srv-hy7z5 systemd[5124]: Reached target Thinking....

If we just want to look at a particular philosopher there is a convenience script for that:

$ npcjournal -f kant
Nov 24 12:13:41 contemplation[5309]: Currently contemplating the moral imperative that demands action based
Nov 24 12:13:41 contemplation[5309]: on universal principles, irrespective of personal desires or consequences.
Nov 24 12:14:21 hunger[5339]: Getting hungry...
Nov 24 12:14:22 consumption[5341]: Eating...
Nov 24 12:14:28 contemplation[5350]: Currently contemplating how the mind shapes our experience, moulding
Nov 24 12:14:28 contemplation[5350]: reality as we perceive it.
Nov 24 12:14:59 hunger[5387]: Getting hungry...
Nov 24 12:15:02 consumption[5400]: Eating...
Nov 24 12:15:26 contemplation[5432]: Currently contemplating the perspective that time and space are not
Nov 24 12:15:26 contemplation[5432]: external conditions but subjective forms of our intuition.

Summary

In this part, we’ve looked at the multi-user capability of Linux and how we can use it to model multiple philosophers, each isolated from one another in their own process space.

We’ve created a shared area they all can access and used standard filesystem tools to allow them all to access that shared space fairly.

We’ve used the journal to see the entire simulation in action and filtered it down just to look at what an individual philosopher is doing.

Next, we need the philosophers to obtain the right number of forks to eat with, which will require the philosophers to talk to each other and negotiate. We’ll cover how to do that in Part 3.

The eating utensils, not child processes. ↩
The GECOS comment is, of course, their reputation after a particularly heavy session of ‘drinking philosophers’, a multi-threaded Java implementation which resulted in a particularly gnarly stack trace that even the combined brains of 13 great philosophers couldn’t interpret. ↩

Solving the Dining Philosophers Problem with systemd - Part 1

2024-01-10T00:00:00Z

Over the years, developers seem to have forgotten that Unix is a Programming Environment and not just something you must install to access your web server. Unix is a powerful multi-user system with numerous tools that have stood the test of time and, with the advent of systemd, we have a new tool that can easily model state machines. Now, we can address a new class of problems using Unix alone.

In this blog post series, we’ll solve the classic “Dining Philosophers” concurrency problem with some of the forgotten mechanisms and tools within the Unix Programming Environment, some advanced capabilities of systemd and a sprinkling of shell scripts to glue it together - all without a single deadlock.

Let’s start by building a simple state machine that moves between the Thinking, Hungry, and Eating states using the user-level systemd facilities.

Create the server

In these examples, we’ll be using Ubuntu on Brightbox, but any modern distro running systemd running anywhere should work.

Create a server and log in with the default ubuntu user:

$ ssh ubuntu@public.srv-hgy08.gb1.brightbox.com
Welcome to Ubuntu 23.10 (GNU/Linux 6.5.0-10-generic x86_64)
...

When you log in, systemd automatically starts a user instance to manage user-level units. You can view this via systemctl:

ubuntu@srv-hgy08:~$ systemctl --user status
● srv-hgy08
    State: running
    Units: 171 loaded (incl. loaded aliases)
     Jobs: 0 queued
   Failed: 0 units
    Since: Mon 2023-11-20 09:41:56 UTC; 1min 19s ago
  systemd: 253.5-1ubuntu6
   CGroup: /user.slice/user-1000.slice/user@1000.service
           └─init.scope
             ├─857 /lib/systemd/systemd --user
             └─858 "(sd-pam)"

Create the states

We can model the three states of the dining philosophers problem using systemd target units. We can make the targets mutually exclusive by stating that they conflict with each other:

# thinking.target
[Unit]
Description=Thinking...
Conflicts=eating.target hungry.target

This means only one of the targets can remain active at any point in time. For a target to transition to another, we need a timer unit.

# thinking.timer
[Unit]
Description=Thinking Period
PartOf=thinking.target

[Timer]
Unit=hungry.target
RandomizedDelaySec=60
OnActiveSec=0
AccuracySec=1us
RemainAfterElapse=false

We make the timer unit part of the target so that it stops at the same time as the target. This combination of RandomizedDelay, OnActive, and Accuracy distributes the transition time from 0 to 60 seconds.

We want to know what the philosopher is thinking about, which we can simulate by running a service to call a script.

# contemplation.service
[Unit]
Description=Contemplation
PartOf=thinking.target
Before=hungry.target

[Service]
Type=oneshot
SyslogFacility=local0
ExecStart=/usr/local/bin/contemplation

We log the script’s output to a different syslog facility, which allows us to find them easily in the log later. A Before restriction ensures that the philosopher logs their thoughts before dealing with their hunger.

Create the contemplation script to output an appropriate thought:

#!/bin/sh
# /usr/local/bin/contemplation
set -e

default_thought="the enigmatic nature of reality:
the existential grasp for an elusive fork, the categorical imperative
of simulated existence, and the irony in questioning the true essence
of the held object."
{
    printf '%s' 'Currently contemplating '
    printf '%s\n' "${default_thought}"
} | fmt
exit 0

Now, we update the target to pull in these new units:

# thinking.target
[Unit]
Description=Thinking...
Conflicts=eating.target hungry.target
Wants=thinking.timer contemplation.service

And repeat the process for the eating and hungry targets.

Running the state machine

To start the simulation, put the files in $HOME/.config/systemd/user and activate the thinking target:

$ systemctl --user start thinking.target

Look in the journal to see the simulation in progress:

$ journalctl -f
Nov 20 10:49:15 srv-hgy08 systemd[1127]: Started thinking.timer - Thinking Period.
Nov 20 10:49:15 srv-hgy08 systemd[1127]: Stopped target eating.target - Eating....
Nov 20 10:49:15 srv-hgy08 systemd[1127]: Stopped eating.timer - Eating Period.
Nov 20 10:49:15 srv-hgy08 systemd[1127]: Starting contemplation.service - Contemplation...
Nov 20 10:49:15 srv-hgy08 contemplation[2163]: Currently contemplating the enigmatic nature of reality: the existential
Nov 20 10:49:15 srv-hgy08 contemplation[2163]: grasp for an elusive fork, the categorical imperative of simulated
Nov 20 10:49:15 srv-hgy08 contemplation[2163]: existence, and the irony in questioning the true essence of the held
Nov 20 10:49:15 srv-hgy08 contemplation[2163]: object.
Nov 20 10:49:15 srv-hgy08 systemd[1127]: Finished contemplation.service - Contemplation.
Nov 20 10:49:15 srv-hgy08 systemd[1127]: Reached target thinking.target - Thinking....
Nov 20 10:49:17 srv-hgy08 systemd[1127]: Started hungry.timer - Hungry Period.
Nov 20 10:49:17 srv-hgy08 systemd[1127]: Stopped target thinking.target - Thinking....
Nov 20 10:49:17 srv-hgy08 systemd[1127]: Stopped thinking.timer - Thinking Period.
Nov 20 10:49:17 srv-hgy08 systemd[1127]: Starting hunger.service - Hunger...
Nov 20 10:49:17 srv-hgy08 hunger[2165]: Getting hungry...
Nov 20 10:49:17 srv-hgy08 systemd[1127]: Finished hunger.service - Hunger.
Nov 20 10:49:17 srv-hgy08 systemd[1127]: Reached target hungry.target - Hungry....
Nov 20 10:49:17 srv-hgy08 systemd[1127]: Started eating.timer - Eating Period.
Nov 20 10:49:17 srv-hgy08 systemd[1127]: Stopped target hungry.target - Hungry....
Nov 20 10:49:17 srv-hgy08 systemd[1127]: Stopped hungry.timer - Hungry Period.
Nov 20 10:49:17 srv-hgy08 consumption[2166]: Eating...
Nov 20 10:49:17 srv-hgy08 systemd[1127]: Starting eating-food.service - Eating Food...
Nov 20 10:49:17 srv-hgy08 systemd[1127]: Finished eating-food.service - Eating Food.
Nov 20 10:49:17 srv-hgy08 systemd[1127]: Reached target eating.target - Eating....

We can filter out the state noise by looking just for the output from our scripts:

$ journalctl -f --facility local0
Nov 20 10:50:44 srv-hgy08 contemplation[2176]: Currently contemplating the enigmatic nature of reality: the existential
Nov 20 10:50:44 srv-hgy08 contemplation[2176]: grasp for an elusive fork, the categorical imperative of simulated
Nov 20 10:50:44 srv-hgy08 contemplation[2176]: existence, and the irony in questioning the true essence of the held
Nov 20 10:50:44 srv-hgy08 contemplation[2176]: object.
Nov 20 10:51:14 srv-hgy08 hunger[2177]: Getting hungry...
Nov 20 10:51:15 srv-hgy08 consumption[2178]: Eating...
Nov 20 10:51:18 srv-hgy08 contemplation[2181]: Currently contemplating the enigmatic nature of reality: the existential
Nov 20 10:51:18 srv-hgy08 contemplation[2181]: grasp for an elusive fork, the categorical imperative of simulated
Nov 20 10:51:18 srv-hgy08 contemplation[2181]: existence, and the irony in questioning the true essence of the held
Nov 20 10:51:18 srv-hgy08 contemplation[2181]: object.

Or, if we want to see just one particular script, we can filter by identifier:

$ journalctl -f --identifier=contemplation
Nov 20 10:51:18 srv-hgy08 contemplation[2181]: existence, and the irony in questioning the true essence of the held
Nov 20 10:51:18 srv-hgy08 contemplation[2181]: object.
Nov 20 10:52:11 srv-hgy08 contemplation[2192]: Currently contemplating the enigmatic nature of reality: the existential
Nov 20 10:52:11 srv-hgy08 contemplation[2192]: grasp for an elusive fork, the categorical imperative of simulated
Nov 20 10:52:11 srv-hgy08 contemplation[2192]: existence, and the irony in questioning the true essence of the held
Nov 20 10:52:11 srv-hgy08 contemplation[2192]: object.
Nov 20 10:52:37 srv-hgy08 contemplation[2197]: Currently contemplating the enigmatic nature of reality: the existential
Nov 20 10:52:37 srv-hgy08 contemplation[2197]: grasp for an elusive fork, the categorical imperative of simulated
Nov 20 10:52:37 srv-hgy08 contemplation[2197]: existence, and the irony in questioning the true essence of the held
Nov 20 10:52:37 srv-hgy08 contemplation[2197]: object.

To stop the simulation, stop the targets:

$ systemctl --user stop thinking.target eating.target hungry.target

or log out.

Summary

In this blog, we’ve created a simple state machine with systemd that moves neatly between states over time and logs its activity in the journal. It’s hardly a fully modelled philosopher, but it’s a good start.

In the next part, we’ll take this simple model and expand it to cover multiple philosophers, introducing the shared dining room where their contemplations take place.