30 Aug
2023
30 Aug
'23
11:38 p.m.
On 2023-08-30 19:19:25 +0200, Jakub Skokan 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.
You mean in foreign mode or in the GuixSD setup? I did not figure out easy
built-in way to switch GuixSD to v2, so if there is one, I would love to know.
Thanks for the feedback!
On 8/30/23 18:45, wolf wrote:
Hm, maybe you did not run `hash guix'?
Actually I re-created the VPS on staging, and, from fresh deploy, this is
sufficient to run the reconfigure without --allow-downgrades:
ssh root(a)37.205.14.33 -t '. /etc/profile; guix pull; hash guix; guix system
reconfigure --no-bootloader /etc/config/system.scm'
I wanted to put it here, maybe it will be of use to someone.
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. 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 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)
There is #:transient?, but I do not know how well/if it interacts with
#:one-shot and system reconfiguration. The script being idempotent is the
correct solution, you are right.
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.
Jakub
PS: Please do not CC: news list, it is only for annoucements.
Sorry about that, I am used to reply-all on mailing lists, and did not notice
that news were CCed.
_______________________________________________
Community-list mailing list -- community-list(a)lists.vpsfree.cz
To unsubscribe send an email to community-list-leave(a)lists.vpsfree.cz
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.