Service restart is now missing in master about pi-hole

[rmceoin]

In our situation I prefer that the gravity script doesn't restart dnsmasq. That allows me to run the script multiple times without bothering the running daemon. Instead I've got a weekly cron script that kicks off gravity and then afterwards tells dnsmasq to reload the configs.

Also, instead of a full restart I'm issuing a SIGHUP to dnsmasq. I decided to go with that due to this statement in the man page::

When it receives a SIGHUP, dnsmasq clears its cache and  then  re-loads
/etc/hosts  and  /etc/ethers  and  any  file given by --dhcp-hostsfile,
--dhcp-optsfile or --addn-hosts.

Here's what my cron script looks like:

#!/bin/sh

#
# cron for pi-hole script
#

if [ -x /usr/local/bin/gravity.sh ]; then
    /usr/local/bin/gravity.sh
    kill -HUP $(pidof dnsmasq)
fi

[jacobsalmela]

I was reading more about a service restart vs. SIGHUP and it does seem that SIGHUP tries to reload the configs without disturbing the daemon. Cool. I'll find a way to implement this.

[mospaeda]

Yes, it would be very interesting from end user perspective to have this script also bundled in the automatic install.
It will let the user to add it in cron

[jacobsalmela]

I haven't deployed a cron file before, but I was thinking number 2 or 3 on this post

[rmceoin]

FYI, I ran into an issue on CentOS and cron. I've got a daily script that ran gravity each day. Unfortunately it just hasn't been updating the actual list. Finally got around to capturing the output of the script which netted:

** Aggregating list of domains...
** Blacklisting 4 domain(s)...
** Whitelisting 61 domain(s)...
** 754599 domains being pulled in by gravity...
** 377703 unique domains trapped in the event horizon.
** Formatting domains into a HOSTS file...
sudo: sorry, you must have a tty to run sudo

Turns out it would fail when trying to copy the list into production:

sudo cp $origin/$accretionDisc $adList

Discovered that the default on CentOS for sudo is to require a tty.

# grep tty /etc/sudoers
Defaults    requiretty

I've commented that out and will see what happens tomorrow. Not sure if this applies to Pi as well.

[jacobsalmela]

So couldn't kill -HUP $(pidof dnsmasq) be just added to the end of the gravity.sh script? Since it doesn't disrupt the daemon, it really shouldn't bother anything, right? Then people can set up their own cron jobs.

[jacobsalmela]

That does not seem to be an issue on Raspbian. That default option does not even exist. Did commenting it out work?

[rmceoin]

Yes, I would think that putting kill -HUP $(pidof dnsmasq) at the end of the script would do the trick.

Yup, commenting out the requiretty worked for CentOS. The cron script works great now. At least in my situation the sudo is actually unnecessary since cron is running as root already, but I don't believe it hurts anything.

[jacobsalmela]

It seems to work quite well just putting kill -HUP $(pidof dnsmasq) in the gravity.sh script, so I think that's what I will go with. Since it isn't stopping the daemon and just re-reads the hosts file, it seems reasonable to do it every time the script runs. Plus, I'm still not quite sure how to deploy a cron file. =)

[mospaeda]

I confirm the kill -HUP option work well (on raspberry PI2 rapbian default install) when placed at the end of gravity.sh script

[jacobsalmela]

Are you putting it at the very bottom of the script?

I put mine below line 110 so it is inside the function.

[mospaeda]

I tested both options. All are working.
In fact it is currently doing the same thing as gravity_advanced function is called in any case of the
if [[ -f $whitelist ]];then statement

It is to be noted that in such case gravity_advanced can even be called out of the if statement for same result.

[jacobsalmela]

So it probably doesn't matter where it goes, so I think I'll put it in the function since that's when we need it to re-read the file after those commands execute. It should make it easier for debugging in the future.