It has made the service structure look really good and robust, the bootup is even quicker too, but I have no idea how it has broken the turnstile user instance.
Although the user instance is launched correctly, and dinitctl can communicate through root, the socket needs to be symlinked to the user's homedir for the user itself to use dinitctl:
$ps aux | grep dinit
root 1 0.0 0.0 6504 4064 ? S 09:45 0:00 /usr/bin/dinit
hitmann 932 0.0 0.0 6368 3684 ? S 09:45 0:00 dinit --user --ready-fd 3 --services-dir /run/turnstiled/1000/srv.932 --services-dir /home/hitmann/.config/dinit.d --services-dir /etc/dinit.d/user --services-dir /usr/local/lib/dinit.d/user --services-dir /usr/lib/dinit.d/user
$dinitctl list
dinitctl: connecting to socket: /home/hitmann/.dinitctl: No such file or directory
dinitctl: perhaps no user instance is running?
#dinitctl -u -d $(find /run/turnstiled/1000 -type d -name 'srv.*') -p /run/user/1000/dinitctl list
[[+] ] boot
[{+} ] system
[[+] ] pipewire (pid: 2016)
[{+} ] dbus (pid: 2010)
[[+] ] pipewire-pulse (pid: 2436)
[[+] ] wireplumber (pid: 2806
$ln -s /run/user/1000/dinitctl ./.dinitctl
$dinitctl list
[[+] ] boot
[{+} ] system
[[+] ] pipewire (pid: 2016)
[{+} ] dbus (pid: 2010)
[[+] ] pipewire-pulse (pid: 2436)
[[+] ] wireplumber (pid: 2806)
Pipewire doesn't work.
I have tried switching back to elogind and messing with pam.
Did something nuke my system badly enough, because i remember a few days ago there was an incipient service structure update which rendered the services unbootable (not the entire system with the dinit-rc problem a bit before)
Slightly offtopic I'd also like to ask about /usr/lib/dinit.d/boot.d/, there are two (unrelated) services in there udevd and getty, but the "type=internal" services are still in their original location. Maybe the new .target stuff with internal tag is supposed to be moved there? It could have something to do with it, as /usr/lib/dinit.d/user (which is not present, i tried creating it+moving the user services there from /etc/dinit.d/user, they start up fine but nothing changed) is now hardcoded as a user path.
Thanks in advance!
I can reproduce this and the workaround is to restart
wireplumber service. Pipewire works but it's... for a lack of a better word, is up too fast. (EDIT: removed
socket-listen and updated
pipewire-dinit, I think it should work now)
Now, the why: Lack of s6-style readiness notification. I will need to pull this patch (https://github.com/chimera-linux/cports/blob/master/main/pipewire/patches/readiness.patch), but it doesn't work with s6 (since it doesn't support
pipevar, only
pipefd. I can probably hardcode it though.
That's intentional. The
.target service is not supposed to be inside
boot.d since it must only be invoked by
boot and in turn,
system.
udevd and
getty are "separate" in a way so they have to be added there.
Spotted the updates to pipewire-dinit&co. yesterday and got to run an update on another machine with this setup now, both pipewire and the default socket are working fine.
Weirdly enough my main machine still acts up, but eh a reinstall is due anyway :) I should stop using gremlins on that one.
Fixed on it too by going over turnstiled.conf and pam stuff once more.