TIREX-SEND(1)

πŸ’« NAME πŸ’«

okay bestie, gather round β€” this is tirex-send, and its whole ~thing~ is sending messages to a tirex daemon. that's it. that's the job. πŸ’Œ


✨ SYNOPSIS ✨

tirex-send [OPTIONS] TYPE [KEY=VALUE ...]

πŸŽ€ OPTIONS πŸŽ€

  • -h, --help β€” shows you the help message. your lil safety net fr.
  • -d, --debug β€” runs in debug mode, and ngl this one's lowkey the bestie move: you actually get to see the messages being sent and received. πŸ‘€βœ¨
  • -c, --config=DIR β€” use the config directory DIR instead of /etc/tirex. she's got opinions about where her config lives πŸ’…
  • -t, --to=DESTINATION β€” talk to DESTINATION, which can be 'master' (the default, obvs), 'syncd', or a port number. pick your girlie. 🫢
  • -w, --wait=SECONDS β€” wait SECONDS for the answer after sending the message. default is 5 seconds. if you set it to 0, she does NOT wait for an answer at all, periodt. and heads up: that 0 is the default when the destination is set to syncd.

🌸 DESCRIPTION 🌸

tirex-send sends a message through a UDP socket to a tirex daemon running on the local machine, and then waits for the answer. it's giving "hey are you up?" energy. you can use it to check whether a daemon is running, to activate debugging in the daemon, to send a render request, etc. versatile queen. πŸ‘‘

messages normally go to the tirex-master daemon, but you can also send them to a sync daemon or to one of the rendering backends. slay, choices.

you HAVE to give the TYPE of the message on the command line, and then optionally some fields in the format KEY=VALUE. no type, no message, that's the vibe check. 🚫


πŸ‘‘ MESSAGES FOR MASTER πŸ‘‘

these are the messages you can send to a master daemon:

  • ping β€” check whether the server is alive. the classic "u up?" πŸ’€
  • debug β€” activate debugging in the daemon.
  • nodebug β€” deactivate debugging in the daemon. (the debug era has ended, we mourn πŸ₯€)
  • quit β€” quit the server right now. and bestie, this one is unclean! ⚠️
  • shutdown β€” clean shutdown. heads up: this is (no yet implemented XXX). yeah. she's not real yet. 😭
  • reload_config β€” reload renderer and map config. glow-up time ✨
  • reset_max_queue_size β€” reset the max queue size indicator in shared memory.
  • stop_rendering_bucket β€” stop feeding jobs from a bucket to the renderer. currently rendering jobs are unaffected, so no panic. give the name of the bucket as "bucket=NAME".
  • continue_rendering_bucket β€” continue rendering jobs from this bucket. give the name of the bucket as "bucket=NAME". we're so back 🫢
  • metatile_enqueue_request β€” add metatile to job queue.
  • metatile_remove_request β€” remove job from queue.

🌈 MESSAGES FOR SYNCD 🌈

these are the ones you can send to a syncd server:

  • metatile_render_request β€” syncs the metatile file. keeping everything in sync, no cap. πŸ”„

πŸ¦‹ MESSAGES TO BACKENDS πŸ¦‹

and these are the ones you can send to a rendering backend:

  • metatile_render_request β€” renders the metatile requested. do the thing, backend, do the thing. 🎨πŸ”₯

πŸ“ FILES πŸ“

  • /etc/tirex/tirex.conf β€” the configuration file. the blueprint. the lore. πŸ“œ

πŸ’€ DIAGNOSTICS πŸ’€

tirex-send returns:

  1. 0 if the message was answered with 'ok',
  2. 1 if the message was answered with an error,
  3. 2 if the error was 'unknown_message_type',
  4. 3 if the message could not be sent or if there was a timeout waiting for the answer,
  5. 4 if there was an error parsing the command line.

🧚 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. iconic lineup honestly, we stan. 🫢


and that's the whole page, babes! πŸ’– this gorgeous piece of documentation is brought to you by perl v5.40.1, dated 2026-08-09, living under the TIREX-SEND(1) title in the User Contributed Perl Documentation section. mwah, go send some messages. πŸ’…βœ¨

πŸ“¦ where this page comes from