A basic Shepherd bug?

A basic Shepherd bug?

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi,

I added the service below to my operating-system, and 'herd status'
prints nothing but hangs. Is that a bug?

Same on reboot. Thanks!

Kind regards
Felix

* * *

  (service fcgiwrap-service-type
           (fcgiwrap-configuration
            (socket "tcp:localhost:3012")))

Re: A basic Shepherd bug?

[Attila Lendvai]

> I added the service below to my operating-system, and 'herd status'
> prints nothing but hangs. Is that a bug?
> 
> Same on reboot. Thanks!


this has probably been fixed in:

https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=9be0b7e6fbe3c2e743b5626f4dff7c7bf9becc16

but it hasn't reached guix yet.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
An economist is a person who spends half his life telling us what will happen and the other half explaining why it didn't.

Re: A basic Shepherd bug?

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Attila,

On Fri, Dec 22 2023, Attila Lendvai wrote:

> but it hasn't reached guix yet.

I hope to test your hypothesis. Will the trick to enable logging [1]
also pull pull in the bug fix?

Alternatively, may I fix the fcgiwrap-service-type to work with the
Shepherd version currently standard in Guix?

The background is that I hope to help with modernizing the GNU bug
tracker. I packaged Debbugs for Guix and deployed it locally to showcase
my efforts (the first step is to move away from Trisquel) but fcgiwrap
should really run as a service before I share the URL with anyone at
FSF. Thanks!

Personally, I follow a different tradition but I very much wish all
folks who celebrate Christmas a happy, wholesome and peaceful holiday
with your loved ones!

Kind regards
Felix

[1] https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00018.html

Re: A basic Shepherd bug?

[Attila Lendvai]

> I hope to test your hypothesis. Will the trick to enable logging [1]
> also pull pull in the bug fix?


yes, you should follow the instructions in [1]; namely:

https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00018.html

together with "Installing development snapshots with Guix" in shepherd's README to add shepherd's channel.

but it will not enable logging, but rather configure your operating system to compile and use the latest commit from the shepherd git repo, which now (probably) contains the fix for your problem.

with the logging you're probably referring to my pending commits in:

https://codeberg.org/attila-lendvai-patches/shepherd/commits/branch/attila

but they are still being polished. i haven't even proposed them yet for inclusion, but i'm already running my servers with that branch.


> Alternatively, may I fix the fcgiwrap-service-type to work with the
> Shepherd version currently standard in Guix?


if you can't make progress with the above, then send me your config, and i'll run it with my shepherd branch, and hopefully the extra logging can help easily fix any issues.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that, too.”
	— Somerset Maugham (1874–1965)

Re: A basic Shepherd bug?

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Attila,

On Sun, Dec 24 2023, Attila Lendvai wrote:

> yes, you should follow the instructions

Thank you! The fcgiwrap service started without trouble.

For anyone following, an experimental deployment of GNU's Debbugs using
Guix System is now available on debbugs.juix.org.

The search is probably not working. It also looks different from the
official version because the code I have does not match what's deployed
(like CSS).

> together with "Installing development snapshots with Guix" in
> shepherd's README to add shepherd's channel.

I got an error and had to add a branch name. (I also asked the Savannah
admins to change the default branch, but that was already done.) Unsure
where to file my patch, I included it below. Will you please forward it
to the right place?

Thank you for your help!

Kind regards
Felix

* * *

From e63c015c28917147376255d843fe083b783c8d11 Mon Sep 17 00:00:00 2001
From: Felix Lechner <felix.lechner@lease-up.com>
Date: Sun, 31 Dec 2023 13:18:56 -0800
Subject: [PATCH] In README, specify 'main' branch in Guix channel declaration.

The author also notified the Savannah administrators that the repository's
default branch should be changed to 'main', presumably after a renaming from
master.
---
 README | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README b/README
index 9ad2e87..5d2cfb3 100644
--- a/README
+++ b/README
@@ -41,6 +41,7 @@ The Shepherd repository can be used as a Guix “channel”.  To do that, change
 
   (append (list (channel
 		 (name 'shepherd)
+                 (branch "main")
 		 (url "https://git.savannah.gnu.org/git/shepherd.git")
 		 (introduction
 		  (make-channel-introduction

base-commit: 07006e41740061305fb774442ea2a6aae13f6bc6
-- 
2.41.0

Re: A basic Shepherd bug?

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Attila

On Sun, Dec 24 2023, Attila Lendvai wrote:

> you should follow the instructions in [1]; namely:
>
> https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00018.html
>
> together with "Installing development snapshots with Guix" in
> shepherd's README to add shepherd's channel.

I did so on a production system which I do not reboot often. Two days
ago, I reconfigured and saw a new Shepherd version being deployed. It
used up a lot of CPU cycles until I rebooted.

It makes sense that upgrading the Shepherd requires a reboot, but maybe
a warning somewhere would be appropriate, if possible. Maybe an email to
root?

Kind regards
Felix

Re: A basic Shepherd bug?

[Attila Lendvai]

hi Felix,


> > you should follow the instructions in [1]; namely:
> > 
> > https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00018.html
> > 
> > together with "Installing development snapshots with Guix" in
> > shepherd's README to add shepherd's channel.
> 
> 
> I did so on a production system which I do not reboot often. Two days
> ago, I reconfigured and saw a new Shepherd version being deployed. It
> used up a lot of CPU cycles until I rebooted.


just to clarify: you `guix system reconfigure` into a new shepherd version, and after that the currently running shepherd init process went 100% CPU, i.e. it was busy looping in one thread?


> It makes sense that upgrading the Shepherd requires a reboot, but maybe
> a warning somewhere would be appropriate, if possible. Maybe an email to
> root?


unfortunately a lot of the infrastructure around guix is lacking explicit formal description of dependencies/requirements. e.g. there's nothing (that i know of) in the shepherd config files (which are generated by `guix system reconfigure`) about what shepherd version they require/assume.

a quick and dirty solution here could be to manually emit an assert into the config file that there's an exact match between the shepherd that generated the config file, and the shepherd process trying to load it. a warning could be issued that the shepherd process is unable to load/process the generated config file until a reboot... which would probably be overkill in most cases.

https://ngnghm.github.io/

this^ blog has interesting thoughts on migration and staged computation. it's a most interesting vision of how these abstractions could be formally captured, and what the resulting computing system would look like.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Love and do what you will.”
	— Augustine of Hippo (354–430), 'A sermon on love'

Re: A basic Shepherd bug?

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Attila,

On Fri, Mar 01 2024, Attila Lendvai wrote:

> you `guix system reconfigure` into a new shepherd version, and after
> that the currently running shepherd init process went 100% CPU,
> i.e. it was busy looping in one thread?

Yes, I used 'guix deploy.' I did so several times before noticing the
unusual load.

I don't usually reboot when changing services, but have to when adding
new ones.  I'm so lazy about it, sometimes it seems we should keep track
of kernel and Shepherd versions separately from other features of the
system. In effect, we would have two types of "system generations,"
namely:

  A. Kernel/PID 1 generation
  B. Features generation (not using the word "services" here)

> a quick and dirty solution

It was just a thought. Ideally, it would appear in a bug tracker so
someone can think about it with the benefit of hindsight later.

> interesting thoughts on migration and staged computation

I just wished for an alert when the code deployed as PID 1 had changed,
but no worries, please. There is so much to do.

Thanks for your (and Ludo's) hard work on the Shepherd. I love it!

Kind regards
Felix

Re: A basic Shepherd bug?

[Ludovic Courtès]

Hi!

Felix Lechner via "Development of GNU Guix and the GNU System
distribution." <guix-devel@gnu.org> skribis:

> The background is that I hope to help with modernizing the GNU bug
> tracker. I packaged Debbugs for Guix and deployed it locally to showcase
> my efforts (the first step is to move away from Trisquel) but fcgiwrap
> should really run as a service before I share the URL with anyone at
> FSF. Thanks!

How far did you go?  It’d be sweet to have a proper Guix System service
for all that!

Ludo’.