I have a strange behavior using 66 on voidlinux when some services in a tree do not start. I have a default tree which has all the services I need. Currently that is:
Name         : default
Initialized  : yes
Enabled      : yes
Starts after : None
Current      : yes
Allowed      : root
Symlinks     : svc->source db->source
Contents     : unbound-log unbound busybox-ntpd-log busybox-ntpd busybox-getty@ tty5
               dhcpcd@ enp2s0-log dhcpcd@ enp2s0 dbus-log dbus sddm-log sddm
That changes a lot, as I am testing/writing frontend service files for void-66-services. Recently I added some services, enabled them and rebooted. They failed to run -that is expected- but other services (most notably sddm) also failed to start. Is that expected? There were no dependencies between the defective services and sddm.
why don't you use the -g option so we can see the status of each service. You are saying when one service fails the entire tree fails to run?
I would strongly recommend to structure services regarding their jobs. Imagine it like folders and make a folder for X, a folder for networking, a folder for server, etc. etc.
Apparently it's not a must, but it makes everything much more accessible and less error prone too. Blocking still seems to be an issue. I bet the team is on it. They recently improved that and I'm sure they will continue to do so.

Your tree shows that it's enabled and initialized though?! You say it's just individual services? Like said, please provide more detailed output :)
Also if you're writing your own services and don't want to take the risk, I'd just create a "debug" or "testing" tree and enable the services there ;) (Which is just another great feature of 66!)
In obarun there is no elogind, but there is consolekit2, and sddm works. Is elogind running inside another tree?
Most DMs I know require such pests (elogind/ck2) to elevate rights when the reboot/shutdown/poweroff options are used, right? So it is possible that a hard dependency on running sddm is such a service. I am guessing here. Marian seems to be more of an sddm expert.
friedmushroom wrotewhy don't you use the -g option so we can see the status of each service. You are saying when one service fails the entire tree fails to run?
These are the services that run successfully so there is nothing to see. I think I can replicate the problem.
Problem in one service stops 66 to either run the tree (I seriously doubt that) or some services of the tree to start.
friedmushroom wroteIn obarun there is no elogind, but there is consolekit2, and sddm works. Is elogind running inside another tree?
Most DMs I know require such pests (elogind/ck2) to elevate rights when the reboot/shutdown/poweroff options are used, right? So it is possible that a hard dependency on running sddm is such a service. I am guessing here. Marian seems to be more of an sddm expert.
There is no need to run elogind from a frontend in this occasion ;) Even if there was, the services had nothing to do with sddm. One was unfinished I had enabled and forgot an the other was haveged, which was work in progress.
marianarlt wrote I would strongly recommend to structure services regarding their jobs. Imagine it like folders and make a folder for X, a folder for networking, a folder for server, etc. etc.
I have not though of that, It will be nice if the number of service frontends continues to grow ;)
marianarlt wrote Your tree shows that it's enabled and initialized though?! You say it's just individual services? Like said, please provide more detailed output :)
Also if you're writing your own services and don't want to take the risk, I'd just create a "debug" or "testing" tree and enable the services there ;) (Which is just another great feature of 66!)
Yes, they were part of a tree (default). Some services did not start and others that are well tested failed...
I am currently testing everything in the same tree (well except from what is inside boot-66serv). Maybe having testing trees and a stable one is a better solution, you are right.

I will try to recreated the problem and give more details ;)

Powered by Obarun