Systemd on /var/log/janio

Monitoring Files and Folders on Linux with systemd path units (and inotifywait for those without root)

Fri, 17 Apr 2026 11:05:00 +0000

In the previous post, macOS’s launchd watched files and directories with WatchPaths to fire scripts automatically when something changed. The model is reactive — instead of running a backup every hour or a conversion every five minutes, the system watches the path on disk and only runs the job when it detects an actual modification. No polling, no waste, no vulnerability window between the change and the action.

Linux has the same capability, but implemented differently and with more options. systemd offers path units — .path files that monitor filesystem paths and automatically activate an associated service when the condition is met. It is the direct equivalent of launchd’s WatchPaths, with the same declarative philosophy: you describe what to watch in a configuration file, the system handles the rest. For anyone working on servers or desktops with systemd, which at this point means practically every mainstream distribution, path units are the right tool.

Munin: internal links for Hugo with AI

Fri, 17 Apr 2026 10:49:00 +0000

In the post about Hugin I explained how I solved the tag and summary problem on my Hugo blog. But there was another problem, less obvious and more annoying: internal links. Those links that connect one post to another, help readers navigate related content, and that Google loves to see on a well-structured site.

The truth is nobody links anything. You write a post about systemd timers, another about cron, another about launchd — and none of the three mentions the others. They’re content islands that could be connected. The obvious solution is to reread every post, remember which others exist, and manually insert links. With 30 posts, it’s doable. With 400, it’s insane.

Exposing homelab services to the internet with Cloudflare Tunnel

Fri, 27 Mar 2026 18:24:00 +0000

In the previous post, I showed how SSH-J.com solves a specific problem: accessing a machine behind NAT via SSH, without opening ports on the router and without relying on a public IP. The reverse tunnel works well for interactive sessions and file transfers, and SSH-J.com as a jump host makes everything trivial to configure. For SSH, it remains the simplest solution I know.

But SSH is just one piece of the puzzle. Anyone who maintains a homelab — even if it’s just a mini PC under the desk or a Raspberry Pi in the corner of the room — inevitably ends up running web services: an RSS reader, a monitoring dashboard, a Gitea, a Jellyfin, an Immich. These services listen on local HTTP ports and work perfectly as long as you’re on the same network. The problem appears when you want to access them from outside — from the office, from your phone on the bus, from anywhere that isn’t your local network.

SSH Behind NAT? SSH-J.com Solves It.

Wed, 25 Mar 2026 22:26:00 +0000

You work remotely, have a server at home, a Raspberry Pi running services, or a machine at the office you need to reach every now and then. The scenario is common and the obvious solution is SSH — already installed, secure, and battle-tested for decades. The problem is that between your machine and the rest of the internet sits a router, a NAT, and possibly an ISP that does not give you a fixed public IP or blocks incoming ports. Suddenly, the most reliable protocol in system administration becomes unreachable from outside your local network.

Scheduling Tasks on macOS with launchd: No cron, No Workarounds

Mon, 23 Mar 2026 21:29:00 +0000

In the previous post I showed how systemd timers replace cron on Debian and Ubuntu servers with concrete advantages: integrated logging, missed execution recovery, declarative dependencies, and resource control. The logic is compelling and the migration is straightforward — as long as you are on a system running systemd. But if your daily routine includes a Mac, it is a different story.

macOS has its own scheduling system, predating systemd and built on a different philosophy. It is called launchd, it has been around since Mac OS X Tiger in 2005, and it is responsible for practically everything that runs in the background on the system — from internal Apple services to that Spotify updater you never asked to install. Despite being the official and recommended way to schedule tasks on a Mac, launchd lives in a kind of blind spot: people coming from Linux tend to reach for cron out of reflex, and Mac users without a sysadmin background do not even know the option exists.

Systemd Timers: Time to Retire cron

Mon, 23 Mar 2026 06:21:00 +0000

If you have been managing Debian or Ubuntu servers for any length of time, you probably have a comfort relationship with cron. One line in the crontab, five scheduling fields, and the path to a script — done. cron has worked this way since the 1970s, and that simplicity is exactly what kept it relevant for so long.

The problem is that “it works” and “it works well in 2026” are different things. When a job fails silently at three in the morning, when you need to figure out which of twenty crontabs scattered across the system contains that one specific task, or when the server reboots and simply misses the execution that should have happened during downtime — those are the moments when cron shows it was designed for an era with different expectations around observability and resilience.