Openbox autostart sequencing – avoiding race conditions?

truelinux · 2025-08-04 15:09:22

I use BunsenLabs Boron on all of my main systems and really appreciate the work that’s gone into it. Leaving the world of the desktop environment is especially liberating.

I’ve been building a minimal Openbox setup from a base Debian install. It's an ongoing goal of mine to better learn the Linux OS "under the hood" and BunsenLabs is one of the best at keeping things lean on older hardware.

I'm not trying to replicate BunsenLabs exactly — just learn from it as I attempt to build a lightweight setup of my own.

I’m trying to better understand the startup order. For ex. - in ~/.config/openbox/autostart, the compositor, panel, wallpaper, and tray apps must launch in a certain sequence in order to avoid data races or timing collisions between processes which might result in missing trays, black wallpapers, etc.

Could you share how you approach this in BunsenLabs? Do you use sleep, run_once, or something else? Any general methods or tools you rely on to avoid startup race issues?

Thanks for your time and for creating and maintaining my favorite distro - I do try to promote it on youtube and other sites whenever I can. Also, best of luck with Carbon - I will be exploring that for sure.

Ben S.

"Machines just got workings and they talk to me.” - Kaylee Frye (Firefly)

Last edited by truelinux (2025-08-05 10:33:07)

brontosaurusrex · 2025-08-04 15:26:48

Can't see much sleeping in here (2s before tint2)
https://github.com/BunsenLabs/bunsen-co … /autostart

I used stuff like this in my own spin

if command -v nitrogen >/dev/null; then
    # Wait for nitrogen to restore wallpaper before launching wbar
    (sleep 12 && nitrogen --restore && LC_NUMERIC=C wbar) &
else
    LC_NUMERIC=C wbar &
fi

which means: do we have nitrogen, if so wait for stuff to load (for 12s) and only then launch nitrogen and only after that launch wbar.
Your milage may vary.

truelinux · 2025-08-04 15:55:12

Thanks — that’s helpful and gives me a better sense of what someone spinning up their own has tried.

I imagine BunsenLabs doesn’t really need much sleep in autostart because the environment is tightly controlled and components are predictable, well-matched, and tested together. So things likely start in the right order without needing manual delays.

In a more DIY Openbox setup like yours (and mine), the mix of tools is less predictable, startup timing can vary, and we might be working with slower or less consistent hardware. That seems to make sleep or similar timing tricks more necessary to avoid things launching too early and failing silently.

Appreciate the explanation — really helpful as I learn to piece this together.

greenjeans · 2025-08-04 16:03:28

Here's mine, I put a lot of sleeps in there, but truly i'm not sure it needs it except for conky, in practice things load pretty fast and I never have an issue so I haven't seen a need to mess with it in a long time.

/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &
nitrogen --restore &
sleep 5 && tint2 &
sleep 7 && volumeicon &
sleep 9 && conky &
sleep 5 && /usr/local/bin/thumbnail-cacher

truelinux · 2025-08-04 16:14:52

Appreciate you sharing this — it really helps to see how others structure their autostart, especially with the sleep timing. As I said in my post, I’ve been wondering about how much delay things really need. Sounds like your approach has stood the test of time!

My current setup runs without any sleeps at all and hasn't caused trouble yet, but I can see why sleeps might prevent trouble in more complex or slower-loading setups. Great to see how others do it - gives me a solid reference point while I’m still figuring out what’s necessary and what isn’t.

Thanks

Last edited by truelinux (2025-08-04 16:26:49)

johnraff · 2025-08-05 02:52:53

Adding a sleep often feels like a bit of a hack to me, but sometimes you've got to do it.
Better is to figure out some way of detecting whether a script is ready to move on to the next step, but that's often more trouble than it's worth.

Here's a nice gnarly example. When launching a Wayland session with lightdm, about 200ms is needed for the VT to switch. For us it was just failing, and coming back to the login window. We were starting to think lightdm was broken when trying to start Wayland, but it turned out to be this:
https://github.com/canonical/lightdm/is … -471208019
https://forums.bunsenlabs.org/viewtopic … 25#p137625

It's possible to make a loop testing if the VT is ready, repeating every 10ms or so, and XFCE are now doing this in xfce4-session https://github.com/xfce-mirror/xfce4-se … 8f2f155205

But what we've provisionally done in /usr/bin/bunsenlabs-session is just throw in a 1s sleep when starting Wayland:
https://github.com/BunsenLabs/bunsen-co … ssion#L121

Doing it "properly" might have saved 1/2 second or so from the login time...

johnraff · 2025-08-05 04:49:15

Sometimes people put the sleep inside a subshell, like the difference between these:

# type 1)
sleep 2
appA &
sleep 5
appB &
other commands

# type 2)
(sleep 2; appA) &
(sleep 5; appB) &
other commands

(btw 'sleep2 && command' is basically the same as 'sleep 2; command' because sleep very seldom returns failure!)

Type 1) waits 2 sec, then forks appA,
then waits 5 sec before forking appB,
then runs "other commands".
So "other commands gets run after a delay of 7 sec.

Type 2) starts counting off the 2 sec for appA, but goes straight on to counting off appB's 5 sec, and running "other commands" with no delay at all.

Sometimes the subshell is what you want - it lets the startup script carry on doing other jobs while a particular app's start is being delayed.

truelinux · 2025-08-05 10:10:39

Thanks, John — that really helped clarify things. I’m still learning the internals of Linux sessions. Your explanation of the timing differences with sleep, and especially the use of subshells to delay app launch without blocking everything else (staggered and in parallel) was eye-opening.

Also realized something that might help others: when using bunsenlabs-session, the usual Openbox autostart file is ignored. Instead, the system uses ~/.config/bunsen/autostart, launched via a script in /usr/lib/bunsen/config. That cleared up why some autostart changes weren’t working on one of my setups.

I use Boron on several pc's - a Toshiba with Intel Duo-Core, a Dell Optiplex with i5 and my daily driver - an HP with i7. A look at htop reveals that my machines love this OS as much as I do. It was really this that led me to start using Openbox and not a heavy desktop environment. And the menu, keybindings, and shortcuts are genius.

Thanks again for the education. Good luck with Carbon!

Ben S.

"Machines just got workings and they talk to me.” - Kaylee Frye (Firefly)

Last edited by truelinux (2025-08-05 11:33:57)

#1 2025-08-04 15:09:22

Openbox autostart sequencing – avoiding race conditions?

#2 2025-08-04 15:26:48

Re: Openbox autostart sequencing – avoiding race conditions?

#3 2025-08-04 15:55:12

Re: Openbox autostart sequencing – avoiding race conditions?

#4 2025-08-04 16:03:28

Re: Openbox autostart sequencing – avoiding race conditions?

#5 2025-08-04 16:14:52

Re: Openbox autostart sequencing – avoiding race conditions?

#6 2025-08-05 02:52:53

Re: Openbox autostart sequencing – avoiding race conditions?

#7 2025-08-05 04:49:15

Re: Openbox autostart sequencing – avoiding race conditions?

#8 2025-08-05 10:10:39

Re: Openbox autostart sequencing – avoiding race conditions?

Board footer