Add runit support #44

Closed
opened 4 months ago by twann · 11 comments
twann commented 4 months ago
Owner

Add runit service

Add runit service

In your last fediverse message you said the service simply executes this command:

/usr/bin/tblockd --daemon --config /etc/tblock.conf

But looking at the service file for openrc there are some more stuff there:

depend() {
    need net
}

Does this mean the service should start when the internet connection is up ?

Also what does the pidfile do here:

command_args="--daemon --no-pid --config /etc/tblock.conf"
pidfile="/run/tblockd.pid"
In your last fediverse message you said the service simply executes this command: ``` /usr/bin/tblockd --daemon --config /etc/tblock.conf ``` But looking at the service file for openrc there are some more stuff there: ``` depend() { need net } ``` Does this mean the service should start when the internet connection is up ? Also what does the pidfile do here: ``` command_args="--daemon --no-pid --config /etc/tblock.conf" pidfile="/run/tblockd.pid" ```
Poster
Owner

But looking at the service file for openrc there are some more stuff there:

depend() {
    need net
}

Does this mean the service should start when the internet connection is up ?

Yes, sorry, I forgot to mention this.

The need net statement does indeed mean that the service should be started once an internet connection is up. However, it isn't mandatory, the daemon can run without an internet connection: it just won't be able to update the filter lists (it will still protect the hosts file against modifications)

Also what does the pidfile do here:

command_args="--daemon --no-pid --config /etc/tblock.conf"
pidfile="/run/tblockd.pid"

A PID file is required, so that tblock knows whether the daemon is running or not. By default, the daemon creates its own pid file under /run/tblockd.pid. However, since OpenRC can create PID files, it is better to let the init system create it. That's why the --no-pid option is passed.

I'm not sure if runit supports setting PID files, but if not, then TBlock can manage its own, simply by not passing the --no-pid option.

> But looking at the service file for openrc there are some more stuff there: > ``` > depend() { > need net > } > ``` > Does this mean the service should start when the internet connection is up ? Yes, sorry, I forgot to mention this. The `need net` statement does indeed mean that the service should be started once an internet connection is up. However, it isn't mandatory, the daemon can run without an internet connection: it just won't be able to update the filter lists (it will still protect the hosts file against modifications) > Also what does the pidfile do here: > ``` > command_args="--daemon --no-pid --config /etc/tblock.conf" > pidfile="/run/tblockd.pid" > ``` A PID file is required, so that `tblock` knows whether the daemon is running or not. By default, the daemon creates its own pid file under `/run/tblockd.pid`. However, since OpenRC can create PID files, it is better to let the init system create it. That's why the `--no-pid` option is passed. I'm not sure if runit supports setting PID files, but if not, then TBlock can manage its own, simply by not passing the `--no-pid` option.

However, it isn't mandatory, the daemon can run without an internet connection: it just won't be able to update the filter lists (it will still protect the hosts file against modifications)

So if I run this daemon when there is no internet and then later I connect to the internet, will TBlock automatically update the filter lists when it gets the chance ?

This is how I would check for internet connectivity in a shell script:

grep -xq 'up' /sys/class/net/[ewu]*/operstate

The exit status of that command will be 0 when the internet is up. Here I used [ewu]* to account for ethernet, wifi, and USB ethernet respectively. But if you want to be more inclusive then maybe you can just use *, I'm not sure if this would give us any false positives in some machines that's my only concern with this.

I'm not exactly sure but I believe openrc uses the same method for checking internet connection, but you should know that it will only tell you if the network interface is up, ie, if you have a wifi/ethernet connection. To really know if the internet connection is working properly I think we might have to ping some popular websites to check that, but I don't think we want to do that here.

I'm not sure if runit supports setting PID files, but if not, then TBlock can manage its own, simply by not passing the --no-pid option.

Every runit service I've seen on my system is just a shell script that starts a daemon or something. And there are ways to get the PID from a shell script - https://www.xmodulo.com/process-id-pid-shell-script.html
And if you start a background process by putting & at the end of a command, then you can use the special variable $! to get the PID of that process. I don't know which PID you want here exactly.

> However, it isn't mandatory, the daemon can run without an internet connection: it just won't be able to update the filter lists (it will still protect the hosts file against modifications) So if I run this daemon when there is no internet and then later I connect to the internet, will TBlock automatically update the filter lists when it gets the chance ? This is how I would check for internet connectivity in a shell script: ```bash grep -xq 'up' /sys/class/net/[ewu]*/operstate ``` The exit status of that command will be 0 when the internet is up. Here I used `[ewu]*` to account for ethernet, wifi, and USB ethernet respectively. But if you want to be more inclusive then maybe you can just use `*`, I'm not sure if this would give us any false positives in some machines that's my only concern with this. I'm not exactly sure but I believe openrc uses the same method for checking internet connection, but you should know that it will only tell you if the network interface is up, ie, if you have a wifi/ethernet connection. To really know if the internet connection is working properly I think we might have to ping some popular websites to check that, but I don't think we want to do that here. > I'm not sure if runit supports setting PID files, but if not, then TBlock can manage its own, simply by not passing the --no-pid option. Every runit service I've seen on my system is just a shell script that starts a daemon or something. And there are ways to get the PID from a shell script - https://www.xmodulo.com/process-id-pid-shell-script.html And if you start a background process by putting `&` at the end of a command, then you can use the special variable `$!` to get the PID of that process. I don't know which PID you want here exactly.
Poster
Owner

So, if I get it right, the service could look like that:

tblockd.run:

#!/bin/sh

# Check every 10 seconds if a network interface is up
while ! grep -xq 'up' /sys/class/net/[ewu]*/operstate; do sleep 10; done

# When an interface is up, launch the daemon
exec tblockd -d -c /etc/tblock.conf
So, if I get it right, the service could look like that: **tblockd.run:** ```sh #!/bin/sh # Check every 10 seconds if a network interface is up while ! grep -xq 'up' /sys/class/net/[ewu]*/operstate; do sleep 10; done # When an interface is up, launch the daemon exec tblockd -d -c /etc/tblock.conf ```
Poster
Owner

Every runit service I've seen on my system is just a shell script that starts a daemon or something. And there are ways to get the PID from a shell script - https://www.xmodulo.com/process-id-pid-shell-script.html
And if you start a background process by putting & at the end of a command, then you can use the special variable $! to get the PID of that process. I don't know which PID you want here exactly.

About the PID, I think I will keep it as it currently is (tblockd creates its own PID file, and tblock checks if it exists or not), because it would require a lot of work to change how it works (since it must be compatible with Windows and macOS). But I'll think about it, thanks for the idea :)

> Every runit service I've seen on my system is just a shell script that starts a daemon or something. And there are ways to get the PID from a shell script - https://www.xmodulo.com/process-id-pid-shell-script.html > And if you start a background process by putting `&` at the end of a command, then you can use the special variable `$!` to get the PID of that process. I don't know which PID you want here exactly. About the PID, I think I will keep it as it currently is (`tblockd` creates its own PID file, and `tblock` checks if it exists or not), because it would require a lot of work to change how it works (since it **must be compatible with Windows and macOS**). But I'll think about it, thanks for the idea :)

I was just giving you some ideas because I have some experience with shell scripting, but you don't have to use them if you have better ideas of your own :)

I was just giving you some ideas because I have some experience with shell scripting, but you don't have to use them if you have better ideas of your own :)

So, if I get it right, the service could look like that:

tblockd.run:

#!/bin/sh

# Check every 10 seconds if a network interface is up
while ! grep -xq 'up' /sys/class/net/[ewu]*/operstate; do sleep 10; done

# When an interface is up, launch the daemon
exec tblockd -d -c /etc/tblock.conf

Yes this would check for internet connection every 10 seconds and run exec tblockd -d -c /etc/tblock.conf when it finds a connection. Note that by "internet connection" I mean "when a network interface is up".

So if I run this daemon when there is no internet and then later I connect to the internet, will TBlock automatically update the filter lists when it gets the chance ?

I'm curious what will happen in this situation.

> So, if I get it right, the service could look like that: > > **tblockd.run:** > > ```sh > #!/bin/sh > > # Check every 10 seconds if a network interface is up > while ! grep -xq 'up' /sys/class/net/[ewu]*/operstate; do sleep 10; done > > # When an interface is up, launch the daemon > exec tblockd -d -c /etc/tblock.conf > ``` > Yes this would check for internet connection every 10 seconds and run `exec tblockd -d -c /etc/tblock.conf` when it finds a connection. Note that by "internet connection" I mean "when a network interface is up". > So if I run this daemon when there is no internet and then later I connect to the internet, will TBlock automatically update the filter lists when it gets the chance ? I'm curious what will happen in this situation.
Poster
Owner

I'm curious what will happen in this situation.

Well, you can configure your daemon to update the filter lists every x hours. So, if an internet connection is not available, the daemon will simply retry after x hours, just as if there was an internet connection.

Also, by default, TBlock keeps downloaded filter lists in cache, which means that, even without an internet connection, the filter lists can still be updated Of course, it doesn't really make sense, unless you remove a filter list: in that case others need to be updated in order to refresh the rules.


For instance, if blocklists test and test2 both block example.com, the rule is stored in the database. When I remove test2, the rule for example.com is also removed. So now I need to update test in order to block again example.com.

EDIT: this is not optimal, but this little issue will probably be fixed in future releases

> I'm curious what will happen in this situation. Well, you can configure your daemon to update the filter lists every `x` hours. So, if an internet connection is not available, the daemon will simply retry after `x` hours, just as if there was an internet connection. Also, by default, TBlock keeps downloaded filter lists in cache, which means that, even without an internet connection, the filter lists can still be updated Of course, it doesn't really make sense, unless you **remove** a filter list: in that case others need to be updated in order to refresh the rules. --- For instance, if blocklists `test` and `test2` both block `example.com`, the rule is stored in the database. When I remove `test2`, the rule for `example.com` is also removed. So now I need to update `test` in order to block again `example.com`. **EDIT:** this is not optimal, but this little issue will probably be fixed in future releases
Poster
Owner

I will mark this issue as fixed, but it will remain open until an AUR package and a Devuan package are built and published :)

I can release an AUR package as soon as I get home, I just wanna test it once on a VM with runit

I will mark this issue as fixed, but it will remain open until an AUR package and a Devuan package are built and published :) I can release an AUR package as soon as I get home, I just wanna test it once on a VM with runit
twann added this to the v2.2.0 milestone 4 months ago
Poster
Owner

Done! It should be working, I just tested it in an Artix VM with runit :)
-> https://aur.archlinux.org/packages/tblock-runit
-> https://tblock.codeberg.page/install/artix/

Done! It should be working, I just tested it in an Artix VM with runit :) -> https://aur.archlinux.org/packages/tblock-runit -> https://tblock.codeberg.page/install/artix/
twann closed this issue 3 months ago

I just installed it on my machine, works like a charm 😀

I just installed it on my machine, works like a charm 😀
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

2022-06-26

Dependencies

No dependencies set.

Reference: tblock/tblock#44
Loading…
There is no content yet.