Date: Fri, 21 Jan 2022 12:47:14 +0100 From: Stefan Esser <se@FreeBSD.org> To: marco+freebsd@crowdsec.net Cc: freebsd-ports@freebsd.org Subject: Re: service management and upgrades Message-ID: <0f2c301f-565a-a2b5-3ed1-1a3ffb86aa2c@FreeBSD.org> In-Reply-To: <CAKjC73aLPf-UXj-ivWM6tG%2Bnu6JKXYeLnhWgzfRY=sv2ypBUAQ@mail.gmail.com> References: <CAKjC73aLPf-UXj-ivWM6tG%2Bnu6JKXYeLnhWgzfRY=sv2ypBUAQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------5AxunA95RSFGeM08xdMpjhts Content-Type: multipart/mixed; boundary="------------yilCAHSoiJh3b2bkBSlG9dyF"; protected-headers="v1" From: Stefan Esser <se@FreeBSD.org> To: marco+freebsd@crowdsec.net Cc: freebsd-ports@freebsd.org Message-ID: <0f2c301f-565a-a2b5-3ed1-1a3ffb86aa2c@FreeBSD.org> Subject: Re: service management and upgrades References: <CAKjC73aLPf-UXj-ivWM6tG+nu6JKXYeLnhWgzfRY=sv2ypBUAQ@mail.gmail.com> In-Reply-To: <CAKjC73aLPf-UXj-ivWM6tG+nu6JKXYeLnhWgzfRY=sv2ypBUAQ@mail.gmail.com> --------------yilCAHSoiJh3b2bkBSlG9dyF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 21.01.22 um 10:03 schrieb marco+freebsd@crowdsec.net: > Hello! >=20 > I have a doubt about service management in the context of my ports. >=20 > 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=3D"YES"; service <name> start). >=20 > My question is: in case of package removal, do I need to stop the servi= ces 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.i= n > <http://pkg-deinstall.in>, otherwise the daemons keep running after the= ir > 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 wa= y 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 wil= l 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 manua= l > intervention. >=20 > But now a third player comes to the field: I have an OPNsense plugin th= at 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. >=20 > What happens if the agent or the bouncer are upgraded and therefore sto= pped? > The OPNsense plugin has no way to know that they are down and must be r= estarted. 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 decid= e 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 && servic= e <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-insta= ll 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? >=20 > 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 --------------yilCAHSoiJh3b2bkBSlG9dyF-- --------------5AxunA95RSFGeM08xdMpjhts Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmHqnUIFAwAAAAAACgkQR+u171r99USQ wggApLSXzUC2THVWxfvSWrcRK2qPuQmnOVOhRcvvG6aN1X2dDbnqi9Zpjr/Kw8om7KAuTdWG7P21 1LP/BhyVpIOgj6Rma1tyCm79tlzYvYoWlWQ46eIbwKjFqkfePEqhonW9UnCnnw4w+/Z3IQgQAsxi 6eB+O3fJzR6aSmR2Xum/Z1UwI1kRODUzddLk/69dNvyqn/eTD2MB+YGNFavVo5Y0+dfBn4jlG4eD pdUdFCJMoAGWLkPTGRPQS9YERS657TJoivfiyzPXzSzHXIWb4WYnYZ0Jd0h4Cxefb0TmMX+yM7jm R2z6BYZv+5dnvuOiku7gdReywXP9j2NP3bPSGyfL/w== =l9y+ -----END PGP SIGNATURE----- --------------5AxunA95RSFGeM08xdMpjhts--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0f2c301f-565a-a2b5-3ed1-1a3ffb86aa2c>