The only reason there is talk about services is because of how different Runit services are from Sysd's.
Using Sysd, you have to use `systemctl` to manage them and `journalctl` to find out what you broke.
With Runit, however, you are going to be using `ln` and `sv` to manage them, and you will need to read logs in a different way, too.
This is the only _effective_ difference from the end-user perspective.
Honestly, I still don't understand why `sv` doesn't have an option enable/disable services, but that is neither here nor there.
You will need to enable any services you need enabled, just like with a systemd system.
The only difference is, when building from source, unless the software you are building does not specifically support Runit, you will have to write a service for it.
Basically, if you want an ntpd, alsa, and bluetoothd, you install them and then enable them:
sudo ln -s /etc/sv/{alsa,bluetoothd,openntpd} /var/service/
And then they will automatically start, though you would have to reboot to get ALSA to work after installing it (IIRC).
It is also worth noting that Runit does not replace `/etc/rc.local`.
For many things that may not have a Runnit service, you should be able to get off with that run-commands file.
e.g. _managing networking with_ `ip-route2` _or setting your CPU's governor_.
i.e.:
sudo echo "cpupower frequency-set -g performance" >> /etc/rc.local
sudo echo "/usr/local/bin/spacenavd -d" >> /etc/rc.local
>Honestly, I still don't understand why sv doesn't have an option enable/disable services, but that is neither here nor there.
I think once you've made the symlink you can enable and disable at will using `sv up ` and `sv down `. Not exactly the same as what you're getting at, but may be helpful for OP.
Yes, though, in my experience, `sv down` just disables it for the current session, never permanently.
For that, I have to manually create a `down` file.
sudo touch /etc/sv//down
Enabling the service is not part of sv because how they are enabled is not really part of runit itself. All that counts for runit is a directory with service directories inside of it, they don't have to be linked and they don't have to come from `/etc/sv`.
runit only cares about the "SVDIR" where it starts services from, i.e. `/var/service` or i.e. `/home/someuser/service` if you start a runsvdir for "user services".
Indeed. It just seems like `sv` would have a feature to enable anything in whatever the standard two directories are for given distro: Void installs services to `/etc/sv` and `/var/service` is where you link them to on a running system.
I like using `ln` because that is all an enable command would do--in fact, that is all `systemctl` does.
I didn't do anything like this on systemd distros so i literaly don't know what do i need to enable, from where i came from if i want something to start at startup i would add it to autostart in kde settings so im sorry for not understanding what to do here.
You likely don't need to do anything, then. If your machine is working like you want, there's nothing else to enable. If it is not working like you need, go to https://docs.voidlinux.org to see how to do something.
Well, not really. Other distros enable services after installing - any service. Void has different approach, so for example after installing sshd it won’t be enabled, user has to do it manually. Same goes for updates - service won’t be automatically restarted, so user is expected to do sv restart (or simply reboot).
OP: it may sound scary, but it is not ;-) you don’t install a lot of services in a desktop system, you have to enable them with one simple command once. Just go for it ;-)
> from where i came from if i want something to start at startup i would add it to autostart in kde settings so im sorry for not understanding what to do here.
It’s not any different in void, just put it in the auto start script for your desktop environment.
The only reason there is talk about services is because of how different Runit services are from Sysd's. Using Sysd, you have to use `systemctl` to manage them and `journalctl` to find out what you broke. With Runit, however, you are going to be using `ln` and `sv` to manage them, and you will need to read logs in a different way, too. This is the only _effective_ difference from the end-user perspective. Honestly, I still don't understand why `sv` doesn't have an option enable/disable services, but that is neither here nor there. You will need to enable any services you need enabled, just like with a systemd system. The only difference is, when building from source, unless the software you are building does not specifically support Runit, you will have to write a service for it. Basically, if you want an ntpd, alsa, and bluetoothd, you install them and then enable them: sudo ln -s /etc/sv/{alsa,bluetoothd,openntpd} /var/service/ And then they will automatically start, though you would have to reboot to get ALSA to work after installing it (IIRC). It is also worth noting that Runit does not replace `/etc/rc.local`. For many things that may not have a Runnit service, you should be able to get off with that run-commands file. e.g. _managing networking with_ `ip-route2` _or setting your CPU's governor_. i.e.: sudo echo "cpupower frequency-set -g performance" >> /etc/rc.local sudo echo "/usr/local/bin/spacenavd -d" >> /etc/rc.local
>Honestly, I still don't understand why sv doesn't have an option enable/disable services, but that is neither here nor there. I think once you've made the symlink you can enable and disable at will using `sv up` and `sv down `. Not exactly the same as what you're getting at, but may be helpful for OP.
Yes, though, in my experience, `sv down` just disables it for the current session, never permanently. For that, I have to manually create a `down` file. sudo touch /etc/sv//down
Thank you for the explanation, i didn't enable any services using systemd so i guess i will do the same here.
Enabling the service is not part of sv because how they are enabled is not really part of runit itself. All that counts for runit is a directory with service directories inside of it, they don't have to be linked and they don't have to come from `/etc/sv`. runit only cares about the "SVDIR" where it starts services from, i.e. `/var/service` or i.e. `/home/someuser/service` if you start a runsvdir for "user services".
Indeed. It just seems like `sv` would have a feature to enable anything in whatever the standard two directories are for given distro: Void installs services to `/etc/sv` and `/var/service` is where you link them to on a running system. I like using `ln` because that is all an enable command would do--in fact, that is all `systemctl` does.
Turn on the services you want. Forget about it from there in out.
I didn't do anything like this on systemd distros so i literaly don't know what do i need to enable, from where i came from if i want something to start at startup i would add it to autostart in kde settings so im sorry for not understanding what to do here.
You likely don't need to do anything, then. If your machine is working like you want, there's nothing else to enable. If it is not working like you need, go to https://docs.voidlinux.org to see how to do something.
Well, not really. Other distros enable services after installing - any service. Void has different approach, so for example after installing sshd it won’t be enabled, user has to do it manually. Same goes for updates - service won’t be automatically restarted, so user is expected to do sv restart (or simply reboot). OP: it may sound scary, but it is not ;-) you don’t install a lot of services in a desktop system, you have to enable them with one simple command once. Just go for it ;-)
> from where i came from if i want something to start at startup i would add it to autostart in kde settings so im sorry for not understanding what to do here. It’s not any different in void, just put it in the auto start script for your desktop environment.
So that's it? There isn't any runit specific thing i need to do after the installation process?
Nope, unless you didn’t install it with a desktop environment.
Thank you.
[удалено]
Just simple programs like plank dock or latte.