unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
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’.


  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).