From nobody Fri Jan 21 09:03:59 2022 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AACEB195C259 for ; Fri, 21 Jan 2022 09:04:20 +0000 (UTC) (envelope-from marco@crowdsec.net) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JgD2q6g70z4RGd for ; Fri, 21 Jan 2022 09:04:19 +0000 (UTC) (envelope-from marco@crowdsec.net) Received: by mail-lf1-x135.google.com with SMTP id u14so653174lfo.11 for ; Fri, 21 Jan 2022 01:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crowdsec-net.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=JumTQwSuBfNE9JeDzTvvuyyuVixU+v90jiGVt3rTbuE=; b=5EjU8usv8H6y5B3j/Q22MqXou6poKW7UX7PnnclDvGORwOMMiq+zFb7TwRevXJ99ya NpYbfmsGhw0aeGQFr/dHOakFDGEJbbySlpBJCyxOf2Nstflsllg0FpKWDM73iSeI8Df+ L47jM2fMe4ywHvvEZn17rKCOttb+557PXN8b2TitXLalWawt393fgl1Cx4TaqR2KWp3L mquu1RgFYr5APX4yIAEPrOooQt01wd62zg/z40Zi4pjuPUyIE4vmC85tktUaQL2v327E 22pQs5830eI1u83nLeXRaLt9Ftu9+c1sX/Kxt8a3MWS+fPFHVLFf4cVqW05ICrWR3AQp gj2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JumTQwSuBfNE9JeDzTvvuyyuVixU+v90jiGVt3rTbuE=; b=UnJmjE1kfgTRZS/nqY9LMOj26GhC2Qj9VdAwBe0ptcZ5n32e+ko5ikkafUI5eetI/j 6dd252Hc4RNuRU9ItELOGZO17quP6Rsivr/T0FrEzA1tlSEx7fPoEqcWjFGGGeHSRUzb Zdw1L0eTQGlVqfsbCOZ4jqhRC8i4B7TtQ70KA1LCfQbMgEbdsm/jmuEgQLeczas1/XC4 zl7ipfWWpTwavVwfP3IptF2goomr+xrfo9Rya2kPZWrrvyL4Ge/QrKJXiYSFyW3iPvP6 BO6H2AfUcsp+tqj2mBoggoFwjeJphOljXbnYKqEshb4F6aG28dfGZhjrJGBp6Ru/1HJA Jg9Q== X-Gm-Message-State: AOAM532vyxoVdMrSMbnGii9/mfjOWmH+0sMs1jBO4etQEWDqWUs7txLP +UVx9MVBNQ/6YzqSPuSW59C9j3+5JLrRXplLKrtsnc20GPs1yg37 X-Google-Smtp-Source: ABdhPJw6xrqpgePgvgz0fJ8jASCZdPFcMtz8mYUsD9jF9LCb84g4LfZonOaETKTjfyHdLazlC7lXqAnMlOliYpvdLiQ= X-Received: by 2002:a05:651c:1a06:: with SMTP id by6mr2528470ljb.244.1642755858077; Fri, 21 Jan 2022 01:04:18 -0800 (PST) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 From: marco+freebsd@crowdsec.net Date: Fri, 21 Jan 2022 10:03:59 +0100 Message-ID: Subject: service management and upgrades To: freebsd-ports@freebsd.org Content-Type: multipart/alternative; boundary="0000000000005fb58f05d613e745" X-Rspamd-Queue-Id: 4JgD2q6g70z4RGd X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=crowdsec-net.20210112.gappssmtp.com header.s=20210112 header.b=5EjU8usv; dmarc=none; spf=pass (mx1.freebsd.org: domain of marco@crowdsec.net designates 2a00:1450:4864:20::135 as permitted sender) smtp.mailfrom=marco@crowdsec.net X-Spamd-Result: default: False [-1.47 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[crowdsec-net.20210112.gappssmtp.com:s=20210112]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[crowdsec.net]; DKIM_TRACE(0.00)[crowdsec-net.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.97)[-0.974]; FROM_NO_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::135:from]; MLMMJ_DEST(0.00)[freebsd-ports]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[freebsd] X-ThisMailContainsUnwantedMimeParts: N --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 _enable="YES"; service 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 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 enabled && service 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
Hello!

I have a doubt about service management in t= he context of my ports.

We develop a couple of daemons, we can call = them agent and bouncer.
They work in cooperation and the pkg-messag= e explains how to enable and run them
(sysrc <name>_enable= =3D"YES"; service <name> start).

My question is: i= n case of package removal, do I need to stop the services myself?
I supp= ose yes, so I have put a "service <name> stop" in pkg-deinstall.in, otherwise the daemons ke= ep running after their executable and configuration files are removed.
<= br>
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.
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).

If th= e above is correct I can live with that, even if it requires manual interve= ntion.

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.

What happens if the agent or the bouncer are upgraded and the= refore stopped?
The OPNsense plugin has no way to know that they are dow= n 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: "ser= vice <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 miss= ing or doing wrong?

Thank you for your time and suggestions.
--0000000000005fb58f05d613e745--