respawn? #t doesn't do anything?
Guix's wireguard service is flawed because it will try to start before
DNS is ready, causing it to fail. I tried to fix this by adding
respawn? #t to the service to make it restart until it succeeds.
https://guix.gnu.org/manual/en/html_node/Shepherd-Services.html#Shepherd-Services
;;definition
(define (wg-quick-shepherd-service config)
(match-record config
(wg-quick interface)
(let ((wg-quick (file-append wg-quick "/bin/wg-quick"))
(config (wg-quick-configuration-file config)))
(list (shepherd-service
(requirement '(networking))
(provision (list
(symbol-append 'wg-quick-
(string->symbol interface
(start #~(lambda _
(invoke #$wg-quick "up" #$config)))
(stop #~(lambda _
(invoke #$wg-quick "down" #$config)))
(documentation "Run the Wireguard VPN tunnel")
(respawn? #t))
;;config
(service wg-quick-service-type
(wg-quick-configuration
(interface "test")
(addresses '("10.9.0.3/24"))
(private-key "")
;;(dns '("10.9.0.1"))
(peers
(list
(wg-quick-peer
(name "")
(endpoint "")
(public-key "")
(allowed-ips '("10.0.0.0/24")))
When booted, the service fails, and does not respawn, even though it
says it is configured to respawn. Why is it not respawning?
[#] ip link add test type wireguard
[#] wg setconf test /dev/fd/63
Name or service not known: `:51820'
Configuration parsing error
[#] ip link delete dev test
failed to start service 'wg-quick-test'
This is the GNU system. Welcome.
guixtest login: root
This is the GNU operating system, welcome!
root@guixtest ~# herd status wg-quick-test
Status of wg-quick-test:
It is stopped.
It is enabled.
Provides (wg-quick-test).
Requires (networking).
Conflicts with ().
Will be respawned.
root@guixtest ~# herd status
Started:
+ console-font-tty1
+ console-font-tty2
+ console-font-tty3
+ console-font-tty4
+ console-font-tty5
+ console-font-tty6
+ file-system-/dev/pts
+ file-system-/dev/shm
+ file-system-/sys/firmware/efi/efivars
+ file-system-/sys/kernel/debug
+ file-systems
+ guix-daemon
+ loopback
+ mcron
+ networking
+ nscd
+ ntpd
+ root
+ root-file-system
+ ssh-daemon
+ syslogd
+ term-console
+ term-tty1
+ term-tty2
+ term-tty3
+ term-tty4
+ term-tty5
+ term-tty6
+ udev
+ urandom-seed
+ user-file-systems
+ user-processes
+ virtual-terminal
Stopped:
- wg-quick-test
One-shot:
* host-name
* sysctl
* user-homes
Should Guix Home daemonize Shepherd?
Hello,
I did a quick search in the tracker and the mailing list archives but
couldn't find a similar topic, apologies if this was already
discussed.
I was playing with Guix Home and I'm a bit surprised by how user
services are managed, especially the Shepherd itself.
Let's say I start from a clean state (I ran 'guix home reconfigure'
and rebooted the Guix machine) and I login via SSH:
$ ssh host
[...]
Service root has been started.
WARNING: Use of `load' in declarative module (#{ g56}#). Add
#:declarative? #f to your define-module invocation.
Starting services...
Service example has been started.
$ exit
On the first login, the user's Shepherd is started and my 'example'
service is run. So far so good.
Now I login again:
$ ssh host
[...]
Starting services...
Service example has been started.
$ exit
The service is restarted again, meaning Shepherd and all the services
were killed when I logged out the first time. Is that expected?
Now, it's even weirder if I open two connections or more:
1$ ssh host
[...]
Starting services...
Service example has been started.
1$ # Don't exit this shell just yet.
2$ ssh host
2$ # Notice how the services weren't started again, I believe
$XDG_RUNTIME_DIR/on-first-login-executed is working as expected.
1$ exit # Now I logout from my first session.
2$ ps waux | grep $service # Nothing! The service has been killed
because I logged out from the first session.
Now, as long as the second session is kept open, the services won't be
restarted automatically, even if I open a third session. I need to
close all existing sessions and login again for the services to be
started.
Finally, I'm not sure Shepherd should share the terminal, it leads to
unfortunate situations like this (in addition to writing messages to
stdout like "Respawning $service", garbling any other process'
output):
$ ssh host
[...]
Starting services...
Service example has been started.
$ ^C # A single ^C will kill Shepherd, so I assume it wasn't properly
put in the background.
Exiting shepherd...
Service example has been stopped.
$ # I lost all my services :(
So, should the Shephered be daemonized when
$XDG_RUNTIME_DIR/on-first-login-executed is set?
I believe it would be a lot less surprising to users, unless the goal
was to prevent any lingering session in the first place.
---
For the record, I'm reproducing the above examples with this configuration:
;; guix home --dry-run reconfigure example.scm
(define-module (example)
#:use-module (guix gexp)
#:use-module (gnu home)
#:use-module (gnu home services)
#:use-module (gnu home services shepherd)
#:use-module (gnu services)
#:use-module (gnu packages base))
(define (example-shepherd-service _)
(list
(shepherd-service
(documentation "Example service.")
(provision '(example))
(start #~(make-forkexec-constructor
(list #$(file-append coreutils "/bin/sleep") "60")
#:log-file (string-append (getenv "XDG_LOG_HOME")
"/example.log")))
(stop #~(make-kill-destructor)
(define example-service-type
(service-type
(name 'example)
(extensions
(list
(service-extension home-shepherd-service-type example-shepherd-service)))
(default-value #nil)
(description "Example service")))
(home-environment
(services
(list (service example-service-type
Package's inputs for developer?
Hi Guix, I often find my self using inheritance of package to add native-inputs that are not stricly necessary for building the project, but are used for developement purpose like so: - (define base-native-inputs (list ...)) (define my-package (package ... (native-inputs base-native-inputs) ...)) ;; Developers version (package (inherit my-package) (native-inputs (append base-native-inputs (list gdb lcov - I guess this is the correct way of doing it or perhaps I should put gdb and lcov in the base-native-inputs?. But I was thinking that perhaps something like `(developer-inputs (list gdb lcov))` would be better, since these inputs are not stricly necessary for building the package. Regards, old -- Olivier Dion Polymtl
Packages for old Emacs versions
Hi, reading [0], I would like to ask if there is any interest in up-streaming the work I have been doing to build old versions of Emacs using Guix (the main use-case is to help with testing Emacs packages on various versions)[1]? My fear is that with further upstream development, there might be conflicts between the packages I inherit from (emacs, emacs-no-x, emacs-minimal) and the packages I have definined in [1]. An easy fix might be to not rely on the upstream package definitions, but I am not certain if there are any down-sides I haven't considered. Of course, if the Guix project isn't interested in providing old versions of packages, then I will continue look into maintaining my own channel. [0] https://guix.gnu.org/manual/en/html_node/Creating-a-Channel.html [1] https://git.sr.ht/~pkal/guix-emacs-historical -- Philip Kaludercic
Re: ‘gnu: Add go-github-com-niemeyer-pretty.’
> + (define-public go-github-com-niemeyer-pretty > + (package > +(name "go-github-com-niemeyer-pretty") > +(version "0.0.0-20200227124842-a10e7caefd8e") > +(source > + (origin > +(method git-fetch) > +(uri (git-reference < + (url "https://github.com/niemeyer/pretty";) > + (commit (go-version->git-ref version Why package the fork niemeyer/pretty instead of upstream kr/pretty? Also, where does this version number come from? Looking at pkg.go.dev, the version number is 0.3.0, not 0.3.0-$foo-$bar. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
