GNU bug report logs - #62584
[PATCH] services: Add error/success service type.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62584 in the body.
You can then email your comments to 62584 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: guix-patches <at> gnu.org
Cc: Ludovic Courtès <ludo <at> gnu.org>
Subject: [PATCH] services: Add error/success service type.
Date: Sat,  1 Apr 2023 09:28:42 +0200

* gnu/services/base.scm (error/success-boot-gexp): New procedure.
(error/success-service-type): New variable.
(%base-services): Add an instance of it.
* doc/guix.texi (Base Services): Document it.
---
 doc/guix.texi         | 26 ++++++++++++++++++++++++++
 gnu/services/base.scm | 27 +++++++++++++++++++++++++++
 2 files changed, 53 insertions(+)

Hello Guix!

A while back, we committed a change that removed the boot-time
message we’d been seeing, “error in finalization thread: Success”:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=168a7933c0e138dc7061a3f0dc96871e16da5c5f

This change was not universally acclaimed.  Some complained that
the boot process had seemingly become opaque because it’s now harder
to tell whether it’s making progress successfully, while others
were disappointed that their newly acquired sticker had become
obsolete.

This patch reinstates that message.  The previous implementation
worked by closing a file descriptor that Guile relied on internally.
The new implementation takes a different approach, with the
error-reporting device implemented right into the service, which
should give us more flexibility—e.g., the service could be extended
to report other error codes.

The new ‘error/success-service-type’ is added to ‘%base-services’,
the default list of system services.  I think it’s good to have it
by default, but that’s something we can discuss.

Feedback welcome!

Ludo’.

diff --git a/doc/guix.texi b/doc/guix.texi
index a58ea8f9ec..605ed648c4 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -19007,6 +19007,32 @@ about the Pluggable Authentication Module (PAM) limits, refer to the
 @samp{pam_limits} man page from the @code{linux-pam} package.
 @end defvar
 
+@cindex success, and error (service type)
+@cindex error, and success (service type)
+
+@defvar error/success-service-type
+This is the service type for the iconic ``error in finalization thread:
+Success'' boot-time message that long-time Guix System users are
+familiar with.  It is part of @code{%base-services} (enabled by
+default).
+
+New users who do not feel the need for this service can disable it by
+filtering it out of their service list.  For instance, if you are using
+@code{%desktop-services}, you can change your operating system
+configuration like so (@pxref{Service Reference,
+@code{modify-services}}):
+
+@lisp
+(operating-system
+  ;; @dots{}
+  (services (modify-services %desktop-services
+              (delete error/success-service-type))))
+@end lisp
+
+However, we do not recommend it as you could lose sight of how weird and
+beautiful your system is.
+@end defvar
+
 @defvar greetd-service-type
 @uref{https://git.sr.ht/~kennylevinsen/greetd, @code{greetd}} is a minimal and
 flexible login manager daemon, that makes no assumptions about what you
diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index e063828d3b..5479cd63cf 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -248,6 +248,8 @@ (define-module (gnu services base)
             pam-limits-service-type
             pam-limits-service  ; deprecated
 
+            error/success-service-type
+
             greetd-service-type
             greetd-configuration
             greetd-terminal-configuration
@@ -2990,6 +2992,29 @@ (define %qemu-static-networking
    (provision '(networking))
    (name-servers '("10.0.2.3"))))
 
+
+;;;
+;;; The iconic error/success message service.
+;;;
+
+(define (error/success-boot-gexp _)
+  #~(begin
+      (display "error in finalization thread: Success\n"
+               (current-error-port))
+      (sleep 2)))           ;let the user notice--all this hasn't been in vain
+
+(define error/success-service-type
+  (service-type
+   (name 'error/success)
+   (extensions
+    (list (service-extension boot-service-type
+                             error/success-boot-gexp)))
+   (default-value 42)
+   (description
+    "This service prints the iconic error/success message at boot time.  The
+message acts as a lighthouse for seasoned users--and seasoned users to
+be!--who immediately know, when they see it, that everything's alright.")))
+
 
 ;;;
 ;;; greetd-service-type -- minimal and flexible login manager daemon
@@ -3364,6 +3389,8 @@ (define %base-services
 
         (service sysctl-service-type)
 
+        (service error/success-service-type)
+
         (service special-files-service-type
                  `(("/bin/sh" ,(file-append bash "/bin/sh"))
                    ("/usr/bin/env" ,(file-append coreutils "/bin/env"))))))
-- 
2.39.2

Message #8 received at 62584 <at> debbugs.gnu.org (full text, mbox):

From: 宋文武 <iyzsong <at> envs.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 62584 <at> debbugs.gnu.org
Subject: Re: bug#62584: [PATCH] services: Add error/success service type.
Date: Sat, 01 Apr 2023 18:34:54 +0800

Ludovic Courtès <ludo <at> gnu.org> writes:

> I think it’s good to have it by default, but that’s something we can
> discuss.

Okay, I don't think so...

> +(define (error/success-boot-gexp _)
> +  #~(begin
> +      (display "error in finalization thread: Success\n"
> +               (current-error-port))
> +      (sleep 2)))           ;let the user notice--all this hasn't been in vain

How about make the message and delay customable?

I prefer "No error in finalization thread: Success",
and 2 seconds may not be enough for a slow reader like me!

> +
> +(define error/success-service-type
> +  (service-type
> +   (name 'error/success)
> +   (extensions
> +    (list (service-extension boot-service-type
> +                             error/success-boot-gexp)))
> +   (default-value 42)

What are this 42 is for?


Otherwise look good to me, thank you!

Message #11 received at 62584 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: 宋文武 <iyzsong <at> envs.net>
Cc: 62584 <at> debbugs.gnu.org
Subject: Re: bug#62584: [PATCH] services: Add error/success service type.
Date: Sat, 01 Apr 2023 18:51:17 +0200

Hi 宋文武,

宋文武 <iyzsong <at> envs.net> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> I think it’s good to have it by default, but that’s something we can
>> discuss.
>
> Okay, I don't think so...

Well, naming and defaults are two hard issues in programming.

>> +(define (error/success-boot-gexp _)
>> +  #~(begin
>> +      (display "error in finalization thread: Success\n"
>> +               (current-error-port))
>> +      (sleep 2)))           ;let the user notice--all this hasn't been in vain
>
> How about make the message and delay customable?
>
> I prefer "No error in finalization thread: Success",
> and 2 seconds may not be enough for a slow reader like me!

Ah yes, good points!  We could probably have a configuration record like
we do for other services.  That way, one could write, say:

  (service error/success-service-type
           (error/success-configuration
             (errno EINVAL)
             (message-type 'no-error)
             (delay 10)))

I’d prefer to leave that for a subsequent patch though, so we can first
restore the previous situation.

>> +(define error/success-service-type
>> +  (service-type
>> +   (name 'error/success)
>> +   (extensions
>> +    (list (service-extension boot-service-type
>> +                             error/success-boot-gexp)))
>> +   (default-value 42)
>
> What are this 42 is for?

It’s currently unused but increases the chances that it’ll give the
right answer.

Thanks for your feedback!

Ludo’.

Message #14 received at 62584 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: 宋文武 <iyzsong <at> envs.net>
Cc: 62584 <at> debbugs.gnu.org
Subject: Re: bug#62584: [PATCH] services: Add error/success service type.
Date: Sat, 01 Apr 2023 18:52:58 +0200

BTW, I wrote about the rationale in more detail in a blog post:

  https://guix.gnu.org/en/blog/2023/reinstating-an-iconic-error-message/

Ludo’.

Message #17 received at 62584 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: 宋文武 <iyzsong <at> envs.net>
Cc: 62584 <at> debbugs.gnu.org
Subject: Re: bug#62584: [PATCH] services: Add error/success service type.
Date: Sun, 02 Apr 2023 15:32:14 +0200

Hi!

Ludovic Courtès <ludo <at> gnu.org> skribis:

> BTW, I wrote about the rationale in more detail in a blog post:
>
>   https://guix.gnu.org/en/blog/2023/reinstating-an-iconic-error-message/

In hindsight, seen from April 2nd, it seems that the status quo might be
preferable after all.

Closing!

Ludo’.

Message #24 received at 62584 <at> debbugs.gnu.org (full text, mbox):

From: 宋文武 <iyzsong <at> envs.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 62584 <at> debbugs.gnu.org
Subject: Re: bug#62584: [PATCH] services: Add error/success service type.
Date: Mon, 03 Apr 2023 17:48:41 +0800

Ludovic Courtès <ludo <at> gnu.org> writes:

>> BTW, I wrote about the rationale in more detail in a blog post:
>>
>>   https://guix.gnu.org/en/blog/2023/reinstating-an-iconic-error-message/

A interesting story, thank you!


> In hindsight, seen from April 2nd, it seems that the status quo might be
> preferable after all.
>
> Closing!

Heh, I was asked by several people how to run a command/script
during (or at the end of) system booting, this service does seems a good
to place to satisfy that use case :)

Message #27 received at 62584 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>, 宋文武 <iyzsong <at> envs.net>
Cc: 62584 <at> debbugs.gnu.org
Subject: Re: [bug#62584] [PATCH] services: Add error/success service type.
Date: Tue, 04 Apr 2023 12:59:40 +0200

Hi Ludo,

On Sun, 02 Apr 2023 at 15:32, Ludovic Courtès <ludo <at> gnu.org> wrote:
> Ludovic Courtès <ludo <at> gnu.org> skribis:
>
>> BTW, I wrote about the rationale in more detail in a blog post:
>>
>>   https://guix.gnu.org/en/blog/2023/reinstating-an-iconic-error-message/
>
> In hindsight, seen from April 2nd, it seems that the status quo might be
> preferable after all.
>
> Closing!

Well, I am not sure to understand if it is an April’s fool (so a good
one! ;-)) or a serious patch.

In both cases, I am missing why it would not be possible to have the
default “error = success“, since it is potentially possible to turn it
off and so have something as no error => success.

Emacs has ton of historical weird defaults.  Basically, I do not see the
issue with such defaults if there is an explanation (in the manual,
say).


Cheers,
simon

Message #30 received at 62584 <at> debbugs.gnu.org (full text, mbox):

From: Jakob Honal <jakob.honal <at> gmx.de>
To: 62584 <at> debbugs.gnu.org
Subject: Re: [bug#62584] [PATCH] services: Add error/success service type
Date: Thu, 27 Apr 2023 05:53:39 +0200

[Message part 1 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.