AccelerateNetworks / PagingServer

SIP-based Announcement / PA / Paging / Public Address Server system
GNU General Public License v2.0
28 stars 14 forks source link

The systemd service doesn't work due to issues in autoanswer.py #1

Closed danry25 closed 9 years ago

danry25 commented 9 years ago

Systemd starts autoanswer.py using the following command:

/usr/bin/python /opt/autoanswer.py < /dev/null

This causes the python script to run and exit with (code=exited, status=0/SUCCESS) when the python script should stay alive and wait for inbound calls.

thefinn93 commented 9 years ago

Do the logs show anything?

danry25 commented 9 years ago

Eh, I asked some systemd people and basically systemd pipes that in for every program, the logs don't show anything out of the ordinary besides that.

If I comment out print("Press <ENTER> to quit") and the following line sys.stdin.readline().rstrip("\r\n"), and add while True: time.sleep(10), it will stay alive long term. The problem is it doesn't hold up when it receives calls continuously, and it is the wrong way to do it. I'm not skilled enough in python to figure out how to get it pjsua to not check this part of the script yet, but this is a hacky, half working solution.

        # Wait for ENTER before quitting
        # print("Press <ENTER> to quit")
        # sys.stdin.readline().rstrip("\r\n")

        while True: time.sleep(10)
ghost commented 9 years ago

I've never done any systemd.service files before, but I've looked it up and I see that you can configure the 'stop' action. If, for example, it is made to send a SIGTERM on systemctl stop then we can replace that hackery with signal handling, to wit:


`import signal`

fuckOff() = signal.SIGTERM

if fuckOff:
    sys.exit(0)

Or something like that. I don't know Python well enough yet to example this properly (or systemd either for that matter.)

I will see if I can implement this over the next few days unless someone beats me to it. It will take me some time because of ignorance.

danry25 commented 9 years ago

Mind making this a pull request?

mk-fg commented 9 years ago

Yeah, mandatory stdin is kinda weird thing to have, in general one'd make an endless loop and leave Type=simple in the .service file.

Better way is to let systemd know when the service is actually ready to do its stuff, so that other services with After= deps on it would properly startup and won't hit closed sockets ot such, hence it's usually a good idea to from systemd import daemon and use daemon.notify('READY=1') with Type=notify.

Plus if there's any kind of even loop in the service (which fairly sure we can hook into here), placing daemon.notify('WATCHDOG=1') pings in there would make sure loop won't get stuck on some single blocking task forever (e.g. hung vfs mount, socket, fifo, bug, sleep in code, whatever), without being force-killed/restarted.

Most of it is in #9, but would also need to hook that watchdog call into pjsua event loop, i.e. something like loop.looping_call(10, sd_ping), should do when I'll get to looking more into pjsua bindings.

mk-fg commented 9 years ago

As PJSUA eventloop can run in the main thread, hooked up watchdog in-between lib.handle_events(ms_until_next_ping) as a part of #11.

mk-fg commented 9 years ago

Should be fixed by #9, see also #7.