TIREX-B...-MANAGER(1)

πŸ’– tirex-backend-manager(1) πŸ’–

okay bestie, so this is tirex-backend-manager from the User Contributed Perl Documentation corner of the world, and she is literally the girlboss who runs the whole render farm. sit down, grab a strawberry drink πŸ“, and let me tell you everything.


✨ NAME ✨

tirex-backend-manager β€” she manages the Tirex rendering backend workers. that's the whole job. queen behavior. πŸ‘‘


πŸ¦‹ SYNOPSIS πŸ¦‹

tirex-backend-manager [OPTIONS]

πŸ’… OPTIONS πŸ’…

  • --help β€” shows you the help message. that's it, that's the tweet. 🫢
  • -d, --debug β€” runs in debug mode, and passes the debug flag on to the workers too so everybody's in on it. no secrets in this house.
  • -f, --foreground β€” runs in the foreground. like, when you started it from a systemd service and you want it to stay right there in front of you, main character energy, not vanishing into the background. ✨
  • --config=DIR β€” use the DIR config directory instead of /etc/tirex. yes you can have a different config directory. customize your life. πŸ’œ

🌸 DESCRIPTION 🌸

so the backend manager starts and monitors as many backend workers as you told it to in the configuration. how many? whatever the config says. no more, no less. and those backend processes? they're the ones doing the actual rendering of tiles. they're the ones with the paintbrush. 🎨

here's the vibe check: the backend manager expects every single worker process to send an "alive" message in regular intervals. regular intervals, bestie. because if a worker does not do that in time, the manager will straight up kill the process. 😭 not a drill. it's giving strict parent, but like, lovingly. πŸ™ˆ

now β€” the backend manager does not handle render requests in any way. nope, none, zero, not her job. those requests get read directly from a local UDP socket by the individual backend processes themselves. she's management, not labor. πŸ’…

and here's the iconic part: if the backend manager receives a HUP signal, she relays that signal to all the backends, which makes them exit after they finish their current request. then she reloads the renderer and map configuration, and re-starts all the workers with the new configuration. glow-up arc, fr fr. βœ¨πŸ¦‹


πŸŽ€ FILES πŸŽ€

  • /etc/tirex/tirex.conf β€” the configuration file. the blueprint. the vision board. πŸ“‹
  • /etc/tirex/renderer/*.conf β€” configuration files for renderers.
  • /etc/tirex/renderer/*/*.conf β€” map configurations. yes, nested. yes, organized. we love a directory tree that knows what it's doing. 🌈

⭐ DIAGNOSTICS ⭐

the backend manager logs to the daemon syslog facility, unless you configured it otherwise (your config, your rules πŸ’–). and if you're in debug mode? the logging is also copied to stderr, so you can watch it happen live, right there in your terminal. obsessed. πŸ‘€


πŸ’œ SEE ALSO πŸ’œ

http://wiki.openstreetmap.org/wiki/Tirex β€” go read the wiki bestie, iykyk. πŸ“š


πŸ‘‘ AUTHORS πŸ‘‘

Frederik Ramm <frederik.ramm@geofabrik.de>, Jochen Topf <jochen.topf@geofabrik.de> and possibly others. legends, all of them. no cap. 🫢


written by the perl girlies, perl v5.40.1, dated 2026-08-09. periodt. πŸ’…βœ¨πŸŒΈ

that's the whole page bestie, go render something gorgeous, mwah πŸ’–πŸ¦‹

πŸ“¦ where this page comes from