Hopefully I can clear up some questions for you.
>To which bundle should elogind be added? I added it to default, but
it might be it belongs to boot instead. I just followed the s6 artix
wiki [3] indicating most of the "services" enabled should be included in
the default bundle, but perhaps elogind is one exception. Which bundle
should it be added to? Or should it be added at all? Perhaps it gets
automatically triggered by things depending on it, that if not triggered
by S6 itself, like eudev and some others?
Default should be good enough for elogind. Elogind just keeps track of
login sessions so as long as it's running before you log in (which is
almost guaranteed to happen) you're good to go.
>When running grub-mkconfig, one gets some weird warnings:
Those are harmless. lvmetad is a daemon that comes with lvm2 and if it's
not available/running, then programs just do regular device scanning to
find your lvm partitions.
>The package "libblockdev" requires rebuild. The current version on
world includes python 3.7 stuff, when the world python is 3.8: [...] How
to place a bug requesting rebuild?
Good catch. Arch's package has built against python 3.8 so yeah that's
our fault. We don't have a formal place for bug reports, so the mailing
list and/or the forums are good enough. Alium does the python stuff so
I'll let him know so he can fix it.
>There's a clamav-s6 package providing the clamd "service" for clamav,
but the freshclam "service" doesn't seem available (providing freshclam
-d), and it's pretty useful to keep the DB up to date. Perhaps I can
write my own freshclamd "service" later. How to place a bug or request
for the missing "service"?
Another good catch. I didn't see that Arch's clamav package also comes
with a clamav-freshclam service. I'll update the clamav-s6 package to
include that service (clamav-runit also needs fixing here; I think
clamav-openrc is correct though).
>There's a cpupower-openrc package to provide the "oneshot" cpupower to
set the CPU governos and such. The cpupwer-s6 is missing. I like the
governos set to "on demand", but can live with current "powersave". How
to place a bug or request for the missing "oneshot"?
I'm not too familiar with the openrc package, but I don't think a
separate script package for this is necessary. If all you want to do is
just set some CPU governors on boot up, you can edit the
/etc/s6/rc.local with the commands you want. It'll execute anything
listed there automatically on every boot. I use it to clean my /tmp
directory.
>There's a lm_sensors-s6 package to provide the "oneshot" that
modprobes the modules found by sensors-detect. However the sensord
"service" for monitoring is missing. Not required at all, but the
daemon is part of the lm_sensors package. How to place a bug or request
for the missing "service"?
Went back and doubled checked the arch package and you're right. The
sensord daemon is missing. Also, so is the healthd daemon. I'll add
these to the script soon.
>The way to log stuff, is through s6 itself I understand. So for
looking into logs to see if there are issues, one has to look for the
log file for a particular "service", right? How about "oneshots"? I
also see tty1 is used as stderr for s6 in general, but as that can get
easily polluted, which log can one look for, in order to see those
errors, not depending on tty1? BTW, when logging into tty1, startx is
triggered, so those logs are lost, so the more reason to be able to look
at those errors somewhere else...
The log stuff is a bit of a work in progress. The goal I'm working for
is for all daemons to have a daemon-srv (the actual service) and
daemon-log (the logger) and for them to log themselves to
/var/log/daemon with s6-log. s6-log has its own log rotation and all
that fancy stuff (you can change the default options which were
arbitrarily selected by going to /etc/s6/sv/daemon-log/conf if you
want). I think most of the "important" services (dhcpcd, dbus, etc.)
have this implemented already but not every service in s6 works like
this at the moment. Of course, if something currently does not use
s6-log and you'd like it to, you're more than welcome to let me know.
Otherwise, yeah it just spits onto tty1. If you have syslog daemon
running, then that will probably catch the logs instead if it's running
first. The printing on tty1 thing is a result of a compile option with
s6-linux-init that I decided to enable. It's a little noisy, but I
figure it's better than having nothing at all. As for oneshots,
currently none of them log anything (aside from dmesg on startup). I'm
not really sure if there's too much of a point? You'll know very quickly
if mount doesn't work, but if you think there's a particular oneshot
that really should be logged let me know.
>Has someone successfully made use of dhcpcd + wpa_supplicant in a way
only one of them is up, and preferably the wired one?
I think this already works. I use the wpa_supplicant service on my
laptop (specifying the wireless interface in
/etc/s6/sv/wpa_supplicant-srv/conf). If I plug in an ethernet cable, it
appears to prefer the wired interface (just checking the IP on the
internet), and if I unplug it, it falls back to the wireless connection.
>After booting, on tty1, the prompt whether doesn't show up, or gets
lost mixed on the amount of log from s6. It shows up only after hitting
"enter", and then one doesn't really know when tty1 is ready to be used,
and one can only guess... Is there a way to keep the prompt on top of
other messages, meaning, while there's no login, make the bottom of tty
to be the prompt, and make it always visible?
The s6 stuff prints over it. It's because tty1 (provided by
s6-linux-init) is compiled to print out a bunch of stuff like that.
There's a couple of things you could do here though. 1. If you're using
daemons with the fancy s6-log setup (as described above), they won't
print anything to the tty1 ans the logger catches all the messages and
moves them elsewhere. 2. By default, s6-rc is set to be rather verbose.
In /etc/s6/current/scripts/runlevel, you could get rid of the "-v2"
arguments in the s6-rc calls if you wanted to. I think the combination
of those two things should get rid of all the stuff printing on tty1 on
boot. Perhaps the s6-rc calls could be changed to be less verbose, but
then again maybe someone like the "daemon starting up" messages.
> Once again, big thanks to the devs, great work, flawless base
installation, and working solution, which to be honest, although non
systemd, totally feels like arch, so besides having to spend a bit of
time to get familiar with the basic s6 commands, it's just like business
as usual with arch.
Thanks for the feedback!
More information about the artix-general
mailing list