I recently reinstalled OpenBSD on my laptop to start with a clean slate (I’ve written an article for anyone who’s interested). My setup was perfect: an encrypted drive, black backgrounds and dark themes everywhere in Xenocara (OpenBSD’s fork of X), Xenodm, Qt and GTK, i3 as the window manager with all the right keyboard shortcuts, great. After a period of inactivity, my computer locked itself (for security reasons), and I had to type my password twice to unlock the system.
I was so pleased with my setup, and this tiny bug was spoiling my enjoyment. It was a pebble in my shoe that annoyed me every time the screen locked automatically, I had to sort this problem out.

Source of the problem

Automatic locking works as follows:

  1. xidle, a program included with Xenocara, receives a message from the X server when there is inactivity and runs a program. In my case, it runs i3lock.
  2. i3lock, the lock screen program included with i3, locks the screen until the user enters their password.

The command looks like this:

xidle -timeout 60 -program '/usr/local/bin/i3lock -c 000000'

At first, I thought the problem was on my end. I checked to see if xidle was running twice, once in my X configuration and once in i3. I read the xidle documentation in case I’d missed something, but I hadn’t. On Reddit , someone had the exact same problem, but none of the replies provided a solution. I switched to debug mode.

I opened a second terminal after the screen locked automatically, and I checked the running processes, i3lock was running twice.
I launched i3lock manually from my terminal: OK.
I ran xidle manually: NOK.

So the problem was with xidle; i3lock was not to blame. All that was left for me to do was to figure out what xidle was doing wrong. I created a small script that writes the time to a file, and I modified the command so that xidle would call that script, and that’s when I figured it out.
After 60 seconds, when xidle called the script, the date was written to the file. And it was written a second time whenever I moved my cursor or pressed a key on my keyboard. There was no doubt about it: it was a bug in xidle.
That meant that xidle launched i3lock once after the timeout, and a second time when I started typing my password. That explains why I had to type my password twice.

I could have simply decided to use an alternative to xidle, such as xss-lock. In fact, that’s probably what the people who discussed the problem on Reddit three years ago did. But I didn’t.

Investigation

I downloaded the Xenocara code and looked into how xidle worked.
As I continued my research online, I also discovered that FreeBSD had encountered the same problem … and had fixed it.

I looked at the patch, which was very simple, and saw that it was fully compatible with Xenocara. I tested it on my computer, and it fixed the problem. It was time to fork Xenocara and submit a patch.

Fork and submit the patch

I forked the Xenocara GitHub repository and applied the patch to keep a record of it. Then I followed the same procedure as for my doas patch : I exported the patch to a file and sent an email to the mailing list.

Why contribute?

You could say I’m nitpicking, I could have used a different program and saved time, so why did I take the time to understand and fix the problem?
Because I don’t just sell OpenBSD services; I use it every day.

It was a minor bug, but it makes my day-to-day life easier and gives me the satisfaction of a job well done. And it’s so rewarding to be able to solve problems on your own. That’s part of what it means to be an OpenBSD administrator.

If you need an expert to audit, migrate, or maintain your servers, check out my services or contact me .