Live SSL certificate reload

[toots]

Discussed in https://github.com/savonet/liquidsoap/discussions/3759

^{Originally posted by **gAlleb** February 21, 2024} Hello there, friends! I've got a question regarding the process of cert renewal when it's included into liquidsoap. Here is the logic: I've got a fucntion with harbor ``` def json_data(request) = some function end transport = http.transport.ssl( certificate="/home/radio/ssl/fullchain.pem", key="/home/radio/ssl/privkey.pem" ) harbor.http.register.simple(transport=transport,port=8007, method="GET", "/liquidsoap", json_data) ``` So it reads my certs and works. When it's time to renew the certs - I have a following hook for liquidsoap certs and icecast as well (inside certbot): ``` post_hook = cat /etc/letsencrypt/live/www.radio/fullchain.pem /etc/letsencrypt/live/www.radio/privkey.pem > /etc/icecast2/cert.pem && service icecast2 restart && cp /etc/letsencrypt/live/www.radio/fullchain.pem /home/radio/ssl && cp /etc/letsencrypt/live/www.radio/privkey.pem /home/radio/ssl && chown -R radio:radio /home/radio/ssl ``` What's next? Should I restart liquidsoap and add a command for that? Cause I don't want to restart it :)) Any other option beside hiding behind proxy? (Cause now I'm having all of this proxied through dedicated domain on 443) Don't know why I need this just wanna know the logic. Does Liquidsoap "watch" cert files? If it dosen't may be there should be an option for that? Thank you!!!

[Moonbase59]

I seem to remember icecast-kh has a "live" config reload, without interrupt things too much. Do we have that for Liquidsoap, too? (Might be difficult I guess.)

Being able to send it a SIGHUP or the like would be nice, and if it has to restart, maybe it could do…

If I do a kill -s SIGHUP 3547759 right now (3547759 being the pid of liquidsoap), I only get a message Aufgelegt ("Hung up") and LS terminates.

Using SIGHUP to signal "reload config" & flush buffers, reopen logs is quite common nowadays. Originally (when we had acoustic couplers and flakey telephone lines) it meant "a terminal session had hung up". But it’s the only signal that doesn’t answer back, and using this well-known technique follows the principle of least surprise.

(Must smile when I read this… How far have we progressed! Remembering working with a serial line at 150 baud, 24 lines of 40 characters, accessing a CompuServe node a country away. And that was in the 1970’s, not so long ago.)

[toots]

Not yet, some cool feature we plan on working on. Maybe for 2.3.x.