Date: Fri, 21 Jan 2022 10:03:59 +0100 From: marco+freebsd@crowdsec.net To: freebsd-ports@freebsd.org Subject: service management and upgrades Message-ID: <CAKjC73aLPf-UXj-ivWM6tG%2Bnu6JKXYeLnhWgzfRY=sv2ypBUAQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
--0000000000005fb58f05d613e745 Content-Type: text/plain; charset="UTF-8" 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? I suppose yes, so I have put a "service <name> stop" in pkg-deinstall.in, otherwise the daemons keep running after their executable and configuration files are removed. 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. 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). 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 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". I have found nothing of the sort in the port repository, the post-install is usually for configuration and does not run services. What am I missing or doing wrong? Thank you for your time and suggestions. --0000000000005fb58f05d613e745 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hello!<br><br>I have a doubt about service management in t= he context of my ports.<br><br>We develop a couple of daemons, we can call = them agent and bouncer.<br><div>They work in cooperation and the pkg-messag= e explains how to enable and run them</div><div>(sysrc <name>_enable= =3D"YES"; service <name> start).</div><br>My question is: i= n case of package removal, do I need to stop the services myself?<br>I supp= ose yes, so I have put a "service <name> stop" in <a href= =3D"http://pkg-deinstall.in">pkg-deinstall.in</a>, otherwise the daemons ke= ep running after their executable and configuration files are removed.<br><= br><div>The problem comes with package upgrades - as far as I know I have n= o way to tell a deinstall from an upgrade, so I cannot restart the dead ser= vice in the new post-install function.</div><div>This means every time a pa= ckage is upgraded, its application has to be restarted by the user (and if = the agent goes down, soon the bouncer will go down too).<br></div><br>If th= e above is correct I can live with that, even if it requires manual interve= ntion.<br><br>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 installatio= n time, and it takes care of enabling and starting/stopping them. So far so= good.<br><br>What happens if the agent or the bouncer are upgraded and the= refore stopped?<br>The OPNsense plugin has no way to know that they are dow= n and must be restarted.<br><br>The only solution I found (but not applied = yet) is putting this on the pkg-install of the agent and bouncer: "ser= vice <name> enabled && service <name> start".<br>I= have found nothing of the sort in the port repository, the post-install is= usually for configuration and does not run services.<br><br>What am I miss= ing or doing wrong?<br><br>Thank you for your time and suggestions.<br></di= v> --0000000000005fb58f05d613e745--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKjC73aLPf-UXj-ivWM6tG%2Bnu6JKXYeLnhWgzfRY=sv2ypBUAQ>