(Filing this here rather than as a Salsa ticket because it may
involve changes to other things in Debian, and we may want an extended
discussion.)

Recently DSA updated openssl on tag2upload-manager-01.  Part of the
upgrade process involves finding all processes with the unlinked
library still mapped and sending them SIGTERM.

It appears that this terminated tag2upload-service-manager.  And there
is nothing that restarts it.

(We may not hve noticed this before because I think t2usm has recently
gained a runtime shared library dependency on openssl.  We use reqwest
for outgoing HTTP requests and iirc I didn't manage to get reqwest
with rustls not to indirectly use aws-lc, which is GPL-incompatible,
rather than reqwest with "native-tls" which here is dynamically linked
openssl.)

This is unsatisfactory.  I think probably want to get rid of openssl,
but that doesn't solve the fundamental problem.

Options seem to include:

 1. Make arrangements for t2usm to be restarted if it exits.
     a. wrapper shell script
     b. systemd something something
     c. cron entry that checks minutely, a la the @reboot one

 2. Ask DSA to reboot the host when they do updates.
    (I don't like this much.)

 3. Ask DSA to send a different signal so that t2usm knows to re-exec
    itself.  (Sending SIGTERM is, in principle, wrong.)

Ian.

Having slept on things,

Ian Jackson writes ("Bug#1126570: tag2upload-service-manager restart after administrative SIGTERM"):
...

I intend to do 1(c) on the grounds that it's easy (and very low risk).
Its main downside is that the website and webhook receiveer is down
for up to the retry interval.

I have solidified this theory of mine.  I don't have time to write up
my reasoning now but I will do so.

Ian.

Ian Jackson writes ("Bug#1126570: tag2upload-service-manager restart after administrative SIGTERM"):

FTR, that is now done.  (aws-lc-rs fixed their licence.)

Ian.