Home/ Questions/Q 6604935
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T19:13:23+00:00

I need a reliable way to check if a Twisted-based server, started via twistd

  • 0

I need a reliable way to check if a Twisted-based server, started via twistd (and a TAC-file), was started successfully. It may fail because some network options are setup wrong. Since I cannot access the twistd log (as it is logged to /dev/null, because I don’t need the log-clutter twistd produces), I need to find out if the Server was started successfully within a launch-script which wraps the twistd-call.

The launch-script is a Bash script like this:

#!/usr/bin/bash
twistd \
  --pidfile "myservice.pid" \
  --logfile "/dev/null" \
  --python \
  myservice.tac

All I found on the net are some hacks using ps or stuff like that. But I don’t like an approach like that, because I think it’s not reliable.

So I’m thinking about if there is a way to access the internals of Twisted, and get all currently running Twisted applications? That way I could query the currently running apps for the the name of my Twisted application (as I named it in the TAC-file) to start.

I’m also thinking about not using the twistd executable but implementing a Python-based launch script which includes the twistd-content, like the answer to this question provides, but I don’t know if that helps me in getting the status of the server to run.

So my question is just: is there a reliable not-ugly way to tell if a Twisted Server started with twistd was started successfully, when twistd-logging is disabled?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You’re explicitly specifying a PID file. twistd will write its PID into that file. You can check the system to see if there is a process with that PID.

    You could also re-enable logging with a custom log observer which only logs your startup event and discards all other log messages. Then you can watch the log for the startup event.

    Another possibility is to add another server to your application which exposes the internals you mentioned. Then try connecting to that server and looking around to see what you wanted to see (just the fact that the server is running seems like a good indication that the process started up properly, though). If you make it a manhole server then you get the ability to evaluate arbitrary Python code, which lets you inspect any state in the process you want.

    You could also just have your application code write out an extra state file that explicitly indicates successful startup. Make sure you delete it before starting the application and you’ll have a fine indicator of success vs failure.

    • 0