30 Aug
2023
30 Aug
'23
5:19 p.m.
Thanks for the feedback!
On 8/30/23 18:45, wolf wrote:
This part was pretty annoying. Unlike other init systems, shepherd does
not accept signals to properly shutdown. All it can do is respond to
SIGINT by restarting itself. There's no way to halt using a signal, e.g.
SIGPWR. So we invoke halt from inside the VPS, but even that is
sometimes problematic as you say.
The available cgroup version depends on the host. So far we have cgroups
v1 everywhere, migration to v2 is planned:
https://kb.vpsfree.org/manuals/vps/cgroups
Guix works with cgroups v2, I use it on my dev machine.
Jakub
PS: Please do not CC: news list, it is only for annoucements.
On 2023-08-30 17:00:07 +0200, Jakub Skokan wrote:
[...]
Comments regarding the "known issues" section:
That didn't work for me. I ran guix pull and system reconfigure from the
same shell, but system reconfigure still used some older commit. No idea
why. I was able to workaround it with:
guix describe -f channels > /etc/guix/channels.scm
guix system reconfigure [...]
rm -f /etc/guix/channels.scm
guix pull
...since then it works, but it doesn't make sense to me.
If it worked for you out of the box, I guess I'm fine with it x)
guix system reconfigure requires
–allow-downgrades, why? Something is fishy
with the channels.
Guix after fresh install is a bit funny sometimes. If one runs `guix pull'
before trying the reconfigure, the --allow-downgrades is no longer necessary. I did however run into different issue:
/ssh:root@37.205.14.33:/etc/config $ guix system reconfigure --no-bootloader
system.scm
The following derivation will be built:
/gnu/store/fb4i299scqpgczwgphjmh85k0z0qgmwc-grub.cfg.drv
building /gnu/store/fb4i299scqpgczwgphjmh85k0z0qgmwc-grub.cfg.drv...
/gnu/store/255b46p2w1b06shnh4wjfz2fzs7r3p8h-system
/gnu/store/9nlha7hybazc09bqgrxplq5w480r02pp-grub.cfg
activating system...
making '/gnu/store/255b46p2w1b06shnh4wjfz2fzs7r3p8h-system' the current
system...
setting up setuid programs in '/run/setuid-programs'...
populating /etc from /gnu/store/xz25p33mwywcwv4xnpg2jkr39hci71hg-etc...
shepherd: Starting service host-name...
shepherd: Service host-name started.
shepherd: Service host-name running with value #<unspecified>.
shepherd: Service host-name has been started.
shepherd: Starting service user-homes...
shepherd: Service user-homes has been started.
shepherd: Starting service sysctl...
shepherd: Service sysctl could not be started.
shepherd: Starting service vpsadminos-networking...
guix system: warning: exception caught while executing 'start' on service
'vpsadminos-networking':
Throw to key `%exception' with args `("#<&invoke-error program:
\"/gnu/store/m6c5hgqg569mbcjjbp8l8m7q82ascpdl-bash-5.1.16/bin/bash\" arguments:
(\"/ifcfg.add\") exit-status: 2 term-signal: #f stop-signal:
#f>")'.
guix system: warning: some services could not be upgraded
hint: To allow changes to all the system services to take effect, you will need to
reboot.
There is /ifcfg.del, however (@ (vpsadminos) vpsadminos-networking) does not use
it as #:stop, and even if it did, I do not think that (#:one-shot?) services do
invoke #:stop. I will send a patch for this in due time (turning the service
into "sleep inf", so that #:stop will start to work).
I'd prefer if we could e.g. prevent the service from being restarted. Or
make the script idempotent, so that it wouldn't fail. It makes no sense
to bring down the network just because bash in shebang was updated.
While /ifcfg.del exists, there's no real reason to call it, ever.
halt (graceful
shutdown) has been observed to sometimes hang, please report in
case it's still a problem.
This is sadly sometimes problem on actual physical machines as well, so it might
not be an issue with the template itself. Just FYI. cgroups v1 are
not mounted. cgroups do not seem to be needed by the base
system, contact us in case it's a problem for some service or submit a patch
to the template.
The only high-profile package that explicitly depends on the cgroup v1 is
currently docker afaik, which in a world where podman exists is not that
important. I plan to try to produce a patch moving guix to v2, which should
solve this issue.