Re: [Fetchmail-users] Fetchmail seems to silently fail when I use the --pidfile option

[Alex H. <ah...@au...>]

I solved this with a very helpful suggestion from Matthias. See below.

On 10/12/2020 17:04, Alex Hall wrote:
> Hello,
> I've used fetchmail for a couple years, as a way of pulling emails 
> into the Request Tracker ticket system I set up for my work. I'm 
> trying to better automate it, by setting it up with Monit. To do that, 
> I want to use the --pidfile option when starting or quitting 
> fetchmail, which I've not tried before.
>
> First, the details. I'm on Debian 8, with fetchmail 6.3.26. I 
> installed this from Debian's package manager; I didn't compile any 
> source. I know Debian 8 is outdated, but we're stuck on this server 
> for a while for various reasons. The server reports that this is the 
> most recent version of fetchmail it can find.
>
> In the past, I'd start fetchmail manually (this is part of what I want 
> to automate with Monit). I use this command:
> sudo -u rt-user fetchmail -f /path/rt4/fetchmailrc
>
> To let Monit have a known pid file to monitor, I tried this command:
> sudo -u rt-user fetchmail -f /path/rt4/fetchmailrc --pidfile 
> /var/run/rt_fetchmail.pid
>
> When I run that command in the terminal, nothing at all happens. I get 
> no output, /var/run/rt_fetchmail.pid is not created, and fetchmail 
> doesn't seem to run. I should say here that the fetchmailrc file being 
> used commands fetchmail to start as a daemon. If I leave off the 
> --pidfile bit, the daemon starts as expected. I can then
> sudo -u rt-user fetchmail --quit
> to kill it. Running that quit command after using the --pidfile 
> variant produces no output.
>
> It seems like the --pidfile option causes a silent failure, but I 
> can't figure out what's going on. The log only shows normal mail 
> managing stuff, with no errors that I've found, and the terminal has 
> no output whatsoever.
>
> I've found nothing online about this problem, so am not sure where 
> else to turn. If anyone on this list has ideas, I'd love to hear them. 
> If I've left out any important information, let me know. Thanks for 
> any help.


First, I was getting no output, so let's fix that:

cd ~

touch fetchmail.log

chown rt-user fetchmail.log

sudo -u rt-user fetchmail -f /path/fetchmailrc --nosyslog -d0 --logfile 
/home/my_user/fetchmail.log


Note that you can try --logfile /dev/stderr, but rt-user couldn't write 
to that, so I had to use a file instead. Anyway, when I checked 
fetchmail.log, the problem was right there: rt-user had no permission to 
write to /var/run. This seems glaringly obvious in retrospect.


Fortunately, there's a simple fix:

sudo mkdir -p /var/run/rt_fetchmail

sudo chown rt-user /var/run/rt_fetchmail


Now, amend the original command to use the new subfolder, and we're golden:

sudo -u rt-user fetchmail -f /path/fetchmailrc --pidfile 
/var/run/rt_fetchmail/rt_fetchmail.pid


This, and a --quit command using the same pid file, let Monit control 
fetchmail just fine. I had to add the creation and ownership change for 
/var/run/rt_fetchmail to my server's startup (I used a cron job entry 
with @reboot), but that was the only other step. So far, things are 
working well.


Remember: users can't create pid files in /var/run, you have to use 
subdirectories which you have to set to the right owner first. Also, if 
fetchmail is giving no output at all, use -d0 to disable any daemon 
directives in fetchmailrc (or just skip the rc file completely if you 
know the problem is before anything in that file), --nosyslog to stop 
fetchmail's messages going to the syslog, and --logfile to redirect 
those messages to somewhere you can more easily review them.

>
> --
>
> Alex Hall
>
> ah...@au...
>
>