From: "Ludovic Courtès" <ludo@gnu.org>
To: Carlo Zancanaro <carlo@zancanaro.id.au>
Cc: help-guix@gnu.org
Subject: Re: Knowing which services to restart
Date: Fri, 24 Jul 2020 17:28:55 +0200 [thread overview]
Message-ID: <87h7tx53uw.fsf@gnu.org> (raw)
In-Reply-To: <87blkq9sdl.fsf@zancanaro.id.au> (Carlo Zancanaro's message of "Wed, 08 Jul 2020 21:08:06 +1000")
Hi,
Carlo Zancanaro <carlo@zancanaro.id.au> skribis:
> On Wed, Jul 08 2020, Pierre Neidhardt wrote:
>> Couldn't Guix be smarter about this? Or at least provide a less puzzling message.
>
> This was brought up when we originally implemented upgrading of services on a live system. The discussion about this starts in an email from Ludovic[1], and proceeds from there (although you'll have to skip over some other unrelated conversations).
>
> There are definitely ways that things can be improved. I made an attempt at doing this at the end of 2018[2], but that didn't result in anything being merged into Guix. I don't think we've yet settled on an approach for how to resolve this (and the related issue of automatically upgrading services).
>
> Carlo
>
> [1]: https://issues.guix.info/22039#11
> [2]: https://issues.guix.info/33508
The general issue here is that we cannot safely stop+start a service
without notice, unless the user explicitly said this is OK.
Consequently, in practice, only services that the user explicitly ‘herd
restart’s are up-to-date. It’s OK when you know you what service you
want to update here and now, but it’s suboptimal otherwise.
I figured there’s one way to mostly sidestep the issue: when we have
“socket activation” in the Shepherd, then unused services will be
“stopped” at reconfigure time and thus safe to upgrade. Thus, in
practice, more services will be upgraded by default.
It’d still be up to the user to restart currently running services when
they deem appropriate.
Thanks,
Ludo’.
next prev parent reply other threads:[~2020-07-24 15:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-08 4:56 Knowing which services to restart Matthew Kraai
2020-07-08 8:53 ` Pierre Neidhardt
2020-07-08 11:08 ` Carlo Zancanaro
2020-07-24 15:28 ` Ludovic Courtès [this message]
2020-09-25 13:12 ` Joshua Branson
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h7tx53uw.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=carlo@zancanaro.id.au \
--cc=help-guix@gnu.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).