wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: "Fabian Grünbichler" <fabian.gruenbichler@student.tuwien.ac.at>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: wireguard dkms systemd
Date: Mon, 5 Nov 2018 12:27:44 +0100	[thread overview]
Message-ID: <20181105112744.zxe3kro53f2ez66a@uni> (raw)
In-Reply-To: <87sh0gdomi.fsf@fifthhorseman.net>

On Mon, Nov 05, 2018 at 01:28:37PM +0700, Daniel Kahn Gillmor wrote:
> On Sun 2018-11-04 16:35:07 +0100, Jason A. Donenfeld wrote:
> > FWIW, Ubuntu users got confused with reloading the kernel module (let
> > alone systemd's view of units), so we wound up adding something a bit
> > strange to the postinst:
> >
> > https://github.com/EggieCode/wireguard-ppa/blob/master/debian/wireguard-dkms.postinst#L36-L72
> >
> > Not sure that Debian would want to follow suite with such a thing though...
> 
> i like some of the ideas there, but i don't think i'd want it as-is, for
> at least a few reasons:
> 
>  * the administrator's choice mechanism
>   (/etc/wireguard/.reload-module-on-update) is rather idiosyncratic.
>   Using a single boolean debconf question is probably a better approach.
> 
>  * echoing suggestions to stdout to rmmod/modprobe just before actually
>    doing the thing seems like a recipe for it happening twice.  I think
>    i wouldn't make that prompt if the administrator has already asked
>    the system to do the upgrade.

Ack.

>  * i'm leery of the "systemctl daemon-reload" approach in particular, as
>    mentioned above.  if lots of packages did that in their postinst
>    they'd be interacting weirdly with each other during a multi-package
>    upgrade.

I don't see how reloading systemd units too often can cause any kind of
interference, and in fact debhelper already does this for both the
'restart in postinst' (default in compat 10+) and the 'stop in prerm,
start in postinst' (default in compat <= 9) mode - unconditionally, on
every upgrade of a package that ships an automatically (re)started unit.

random data point: on this system with 1606 maintscripts in place, 93
have some variant of systemctl daemon-reload in them (and 12 even have
multiple calls in one maintscript). on a server running Stretch, the
ratio is 72/597.

unnecessarily reloading does of course prolong the upgrade itself, but
since we can't easily tell that the unit has been modified, and not
reloading in case it has been makes the restart fail, the tradeoff of
always reloading on upgrade seems reasonable to me.

FWIW, I'd like to see some variant of transparent reloading integrated
into the Debian packages (even if disabled by default).

> thanks for the pointer though!

thanks for your work on wireguard in Debian :)
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

  reply	other threads:[~2018-11-05 15:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-20 20:59 wireguard dkms systemd Lucian Cristian
2018-10-20 21:07 ` Robert-André Mauchin
2018-10-21 12:12 ` Jordan Glover
2018-10-21 15:49   ` Lucian Cristian
2018-11-02 13:52     ` Daniel Kahn Gillmor
2018-11-02 23:27       ` Reuben Martin
2018-11-04  3:24         ` Daniel Kahn Gillmor
2018-11-04 15:35           ` Jason A. Donenfeld
2018-11-05  6:28             ` Daniel Kahn Gillmor
2018-11-05 11:27               ` Fabian Grünbichler [this message]
2018-11-06  7:16                 ` Daniel Kahn Gillmor
2018-11-06 13:04                   ` Fabian Grünbichler
2018-11-07  2:29                     ` Daniel Kahn Gillmor
2018-11-05 15:51               ` Jason A. Donenfeld
2018-11-03 11:54       ` Matthias Urlichs
2018-11-04  3:22         ` Daniel Kahn Gillmor
2018-10-21 13:01 ` Jonathon Fernyhough

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181105112744.zxe3kro53f2ez66a@uni \
    --to=fabian.gruenbichler@student.tuwien.ac.at \
    --cc=dkg@fifthhorseman.net \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).