When issuing "service -R" fetchmail stops, but never restart: "fetchmail: lstat: /root/.fetchids: Permission denied" is printed.
"service fetchmail restart" works.
This is due to a difference in how the service command works:
_ with -R it sets HOME=/root
_ without -R it sets HOME=/
I'm in doubt if this is a service (base system) bug or feature.
In any case a simple workaround is to add "export HOME=/" in the first lines of fetchmail RC startup script.
Is it correct that you're using the "Single system-wide fetchmail daemon" mode described at the top of the rc script? Or do you have it configured some other way?
Could you clarify by providing the `fetchmail_*` settings from your rc.conf files?
(In reply to Corey Halpin from comment #1)
Yes and no.
I have both use cases.
rc.conf either contains a simple:
fetchmail_users="a b c d e...
The problem comes up anyway in the same manner.
From what you've reported it seems clear to me that the rc script needs to be setting `FETCHMAILHOME` so that `fetchmail` will be able to find and use idfiles when fetching over POP3. It isn't currently doing that, which is wrong, but sometimes it is wrong that allows `fetchmail` to start anyway.
Your proposed `export HOME=/` at the top of the script is not a good solution because it will cause the system-wide move and the per-user mode both to look in / for that file. It makes everything wrong in the same way.
If I'm correctly understanding what is happening on your system you should be seeing "Cannot open fetchids file ... for writing" errors in your logs. Do you see those? If you do not, then it indicates that I don't yet understand what is failing on your system well enough to know the correct fix. In that case, it would be helpful to see a sanitized copy of your `fetchmailrc` file.
If you are seeing those errors, then I believe the correct fix is to add `fetchmail_home=/var/run/fetchmail` after line 167 and to add `export FETCHMAILHOME=$fetchmail_home` after line 187 in the rc script. Can you try that and report back please?
(In reply to Corey Halpin from comment #3)
> so that `fetchmail` will be able to find and use idfiles when fetching over
I've got the problem with IMAP too.
> If I'm correctly understanding what is happening on your system you should be
> seeing "Cannot open fetchids file ... for writing" errors in your logs.
Actually (but not on all the installations) I see:
fetchmail: lstat: /root/.fetchids: Permission denied
So my interpretation is that it actually cannot *read* /root (which is correct as I have 700 permissions for root and fetchmail starts at nobody).
> If you are seeing those errors, then I believe the correct fix is to add
> `fetchmail_home=/var/run/fetchmail` after line 167 and to add `export
> FETCHMAILHOME=$fetchmail_home` after line 187 in the rc script. Can you try
> that and report back please?
I tried this on a box where I'm using a system wide config (with POP3) and it doesn't help: that's because calls to fetchmail_dump_config will still fail (and will display the above message).
It works, however, if I put the second command as line 172.
In the next week I'll try to distribute this patch to as many systems as possible to see if it works with different configurations (e.g. IMAP with multiple users).
Ah! Yes, you are quite right that the environment needs to be set up before the first call to `fetchmail_dump_config`. It would be best for *both* of those `export` lines to happen after the `required_files` line so that the `fetchmail` that is dumping the configuration sees the same environment as the one that we will later invoke.
I can confirm this is working with per-user configs too.