MESSAGE
DATE | 2020-03-24 |
FROM | Dudemanguy via artix-general
|
SUBJECT | Re: [Hangout - NYLXS] [artix-general] question after/post
|
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! -- artix-general mailing list artix-general-at-artixlinux.org https://lists.artixlinux.org/listinfo/artix-general _______________________________________________ Hangout mailing list Hangout-at-nylxs.com http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|