Re: service management and upgrades

Am 21.01.22 um 10:03 schrieb marco+freebsd@crowdsec.net:
> Hello!
> 
> I have a doubt about service management in the context of my ports.
> 
> We develop a couple of daemons, we can call them agent and bouncer.
> They work in cooperation and the pkg-message explains how to enable and run them
> (sysrc <name>_enable="YES"; service <name> start).
> 
> My question is: in case of package removal, do I need to stop the services myself?

This can be required, e.g. if the running service expects to have access
to files that will have been removed (e.g. to start as sub-processes).

Many ports do not have such a requirement, they process a configuration
file at start-up and expect their data directories to continue to exist,
but can continue to run even if their package has been deinstalled.
This is true for the file serving by the SAMBA server ports, for example,
but not for certain maintenance tasks of those ports.

This allows to upgrade a running service and then to perform a service
restart when the new version is ready to run. It does obviously not work
for all ports - you have to know what you are doing ...

> I suppose yes, so I have put a "service <name> stop" in pkg-deinstall.in
> <http://pkg-deinstall.in>, otherwise the daemons keep running after their
> executable and configuration files are removed.

You could have mentioned that you are talking about the security/crowdsec
port and security/crowdsec-firewall-bouncer, but as I understand it in
the context of a more complex platform. Is this correct?

> The problem comes with package upgrades - as far as I know I have no way to
> tell a deinstall from an upgrade, so I cannot restart the dead service in the
> new post-install function.

You could use a mechanism outside the ports system to enable restarting
of the service. You could for example write a token to a directory that
is under control of the service, which indicates it was running at the
time if de-installation and that it should be restarted.

> This means every time a package is upgraded, its application has to be
> restarted by the user (and if the agent goes down, soon the bouncer will go
> down too).

You do not mention how long those processes could be kept running without
the service. If they can survive over the duration of a "normal" package
upgrade, then you'll only have to manually restart them after a failed
upgrade.

> If the above is correct I can live with that, even if it requires manual
> intervention.
> 
> But now a third player comes to the field: I have an OPNsense plugin that uses
> the above two services. It depends on them at installation time, and it takes
> care of enabling and starting/stopping them. So far so good.
> 
> What happens if the agent or the bouncer are upgraded and therefore stopped?
> The OPNsense plugin has no way to know that they are down and must be restarted.

The plugin could periodically check their status and try to restart them,
if a reasonable scan period can be found.

Maybe the solution is to give the plugin full control over the starting
and stopping the service (but only if the plugin is installed, too).

The service could have a @preunexec clause in the pkg-plist, which lets
the OPNsense plugin expect the service to be stopped and unavailable for
some time. The installation of the new version of the service could then
signal its availability to the running OPNsense plugin, which could decide
whether it wants to restart the service.

If the OPNserve plugin is not installed or configured to start and stop
the service, it could still do it directly via the service command.

> The only solution I found (but not applied yet) is putting this on the
> pkg-install of the agent and bouncer: "service <name> enabled && service <name>
> start".

If the OPNsense plugin is central to running the service, then it seems
best to have it take control of starting the service. There is no need
to disable a service during de-installation, and OPNsense can see that
it had been enabled before the new version has been installed and can
then assume that the new version should be started, too.

> I have found nothing of the sort in the port repository, the post-install is
> usually for configuration and does not run services.

You can make liberal use of @{pre,post}exec and ...unexec in pkg-plist.

> What am I missing or doing wrong?
> 
> Thank you for your time and suggestions.

Let me know if I misunderstood the problem or if the above might work but
is lacking in detail ...

Regards, STefan