I Wrote A Systemd Unit For Logging The Kids Out At Night

I Wrote A Systemd Unit For Logging The Kids Out At Night

INTRODUCTION

There’s a particular kind of modern parenthood that involves negotiating with a 12-year-old who possesses what can only be described as “time blindness.” Bedtime becomes a negotiation, wake-up time becomes a challenge, and the glow of a gaming monitor at 2:00 AM becomes all too familiar. For parents dealing with children who game well past reasonable hours, the struggle is real, pervasive, and often exhausting.

The scenario is all too common: a child who simply cannot conceptualize time when engrossed in a game, who sneaks back onto the family PC the moment parents fall asleep, and who operates on a schedule that seems fundamentally disconnected from the rest of the household. The sleep deprivation, the arguments, the constant monitoring—it all takes its toll.

This is precisely the problem one parent encountered and decided to solve with pure infrastructure ingenuity. Posting to a popular DevOps community, they shared their solution: a systemd unit that automatically disables a user account at 22:00 and re-enables it at 06:30, with clever handling for edge cases like computers being turned off before the scheduled lock time. The unit even runs one minute after boot if the computer was off during the lock period, ensuring the schedule is always respected.

As a senior DevOps engineer and technical writer, I found this solution fascinating not just for its practical application in family management, but as an excellent example of system administration fundamentals executed with precision. Systemd, often maligned or misunderstood in some corners of the Linux community, remains one of the most powerful and flexible init systems available. Using its unit and timer capabilities for time-based access control demonstrates both the technology’s capability and the administrator’s understanding of how to leverage it effectively.

In this comprehensive guide, we’ll explore exactly how to implement a solution like this. We’ll dive into systemd unit fundamentals, walk through creating the specific configuration files needed, examine edge case handling, and discuss broader applications of these techniques in homelab and self-hosted environments. Whether you’re a parent seeking balance in your household, a sysadmin looking to automate access control, or simply interested in the mechanics of Linux service management, this guide has something for you.

UNDERSTANDING THE TOPIC

What is Systemd?

At its core, systemd is a system and service manager for Linux operating systems. It has become the default init system for most major Linux distributions since approximately 2015, replacing older init systems like SysVinit and Upstart. While its adoption has not been without controversy—some administrators appreciate its power and features while others critique its complexity or deviation from Unix philosophy—there’s no denying its prevalence and capability.

Systemd organizes system functionality into “units,” which are configuration files that describe resources that the system knows how to manage. These units come in several varieties:

• Service units (.service): Describe applications or processes to start and manage
• Timer units (.timer): Describe time-based triggers for other units or operations
• Target units (.target): Group other units into logical boot/runlevel states
• Mount units (.mount): Describe filesystem mounts
• Socket units (.socket): Describe network or IPC sockets
• Path units (.path): Describe filesystem paths for triggering actions

For our use case, we’ll primarily work with service units and timer units, leveraging systemd’s powerful time specification language to create schedules that are both precise and flexible.

The Systemd Time Specification

One of systemd’s most elegant features is its human-readable time specification, which appears throughout unit files. This language supports:

• Absolute times: 22:00, 06:30
• Relative times: now + 5min, tomorrow
• Day-of-week specifications: Mon-Fri, Sun-Sat
• Complex combinations: Mon-Tue-Thu-Fri 20:00-22:00

This specification uses a subset of cron-like syntax but with systemd’s particular flavor, supporting ranges, steps, and lists. Understanding this language is crucial for configuring our kid-lock unit effectively.

Why Systemd for This Use Case?

You might wonder: “Why not just use cron? Isn’t that the traditional way to schedule tasks?”

Cron certainly has its place and remains widely used for simple periodic tasks. However, systemd offers several advantages for this specific scenario:

1. Dependency-based activation: Systemd timers can depend on other units being running or not running, enabling sophisticated conditional logic.

2. Integrated logging: Systemd automatically captures service output in the journal, providing excellent observability without additional configuration.

3. Graceful handling of edge cases: The ability to configure what happens when a system boots during a scheduled lock period is built into the timer architecture.

4. User session awareness: Systemd can interact with user sessions and processes in ways that feel more natural than cron’s process-based approach.

5. Standardization: Since systemd is ubiquitous on modern Linux, the solution works consistently across different distributions.

Key Features of the Solution

The parent’s systemd unit implements several noteworthy features worth examining:

• Time-based user disablement: The unit runs at 22:00 each day, disabling the target user account
• Time-based user enablement: The unit runs at 06:30, re-enabling the account
• Boot-time catch-up: If the computer was off during the lock period, the unit triggers one minute after boot
• Weekend consideration: The schedule respects that 06:30 on a Saturday morning shouldn’t result in immediate unlocking

Each of these features demonstrates different aspects of systemd’s capability. Let’s explore how to implement them.

Pros and Cons

Pros:

• No additional software required (systemd is already present)
• Leverages existing Linux infrastructure
• Highly customizable time specifications
• Integrated logging and monitoring
• Works across most modern Linux distributions
• Handles edge cases elegantly

Cons:

• Requires root or sudo access to create system-wide units
• Learning curve for systemd unit file syntax
• Less portable than cron across non-Linux systems
• Debugging can require familiarity with systemctl and journalctl
• Configuration lives in /etc/systemd/system/ which some consider “system-level” clutter

Current State and Future Trends

Systemd continues to evolve, with ongoing development adding features, improving documentation, and addressing community concerns. While alternative init systems exist (openrc, runit, s6, among others), systemd remains the dominant choice for most Linux distributions. Its timer and unit system has stabilized, with the core syntax and capabilities well-established.

For homelab and self-hosted environments specifically, systemd’s reach extends beyond just the operating system—many applications and services also ship with systemd unit files, making familiarity with this system increasingly valuable.

Comparison to Alternatives

vs. Cron:

• Cron: Simpler, more portable, but less feature-rich for complex edge cases
• Systemd: Richer feature set, better integration, but heavier and Linux-specific

vs. Task Schedulers (Windows Task Scheduler, etc.):

• Systemd: Linux-native, scriptable, part of the OS
• Windows Task Scheduler: GUI-driven, Windows-native, different command syntax

vs. Custom Scripts with Sleep Loops:

• Systemd: Robust, handles restarts, built-in time specification
• Custom scripts: Full control, but more code to maintain, more edge cases to handle

vs. Parenting Software/Router-level Controls:

• Systemd: OS-level, works regardless of network, fully customizable
• Router controls: Network-level, may be bypassed, less granular

Real-World Applications

Beyond the parental control use case, systemd timers and units find application in:

• Homelab service management: Starting/stopping services based on time of day
• Backup scheduling: Incremental backups during off-peak hours
• Energy management: Controlling smart home devices based on time
• Security hardening: Disabling unnecessary services during specific periods
• Development environment automation: Starting/stopping development stacks

The parental control example is particularly elegant because it takes a problem domain (children’s screen time) and solves it using infrastructure tools designed for entirely different purposes. This kind of creative application of general-purpose tools is what makes system administration both challenging and rewarding.

PREREQUISITES

Before diving into the implementation, let’s ensure we have everything needed to follow along and create our own systemd units for time-based access control.

System Requirements

Operating System: Any modern Linux distribution with systemd as the init system. This includes:

• Ubuntu 20.04+/22.04+/24.0