Cron <vmail@bwc> /usr/local/bin/fetchmail.pl

Since Linode did a server upgrade on the weekend I've been getting these errors every 10 minutes in my Inbox.

can't lock /var/run/fetchmail/fetchmail-all.lock at /usr/local/bin/fetchmail.pl line 45. Does anyone know what this is and how to fix it?

Line 45 says this:

############## Don't change anything below!
#

openlog("fetchmail-all", "pid", "mail");

sub loganddie {

my($message) = @_;

syslog("err", $message);

die $message;

}

7 Replies

It is possible that the lock file already exists and can't be removed.

Look for the lock file (/var/run/fetchmail/fetchmail-all.lock, as you mention above) and remove it manually.

@IfThenElse:

It is possible that the lock file already exists and can't be removed.

Look for the lock file (/var/run/fetchmail/fetchmail-all.lock, as you mention above) and remove it manually.

I just heard back from my sever admin and he said "the lock file directory that it was looking for didn't exist so I created it."

The errors I was getting has stopped.

By the way, my admin found this too. The DKIM Private Key files had the wrong permissions. They were only readable by the ROOT and lost TGE read bit for the OpenDKIM group. I'm still concerned that when Linode did the server upgrade it caused all these issues.

I don't think Linode is to blame, all they did is migrate and reboot servers, the content is untouched.

Looking at the path you mention in the subject, I would guess that the mistake was on whoever installed the custom script. They probably didn't configure the auto-creation of the /var/run/fetchmail directory, something that would have been taken care of by an RPM package.

@IfThenElse:

I don't think Linode is to blame, all they did is migrate and reboot servers, the content is untouched.

Looking at the path you mention in the subject, I would guess that the mistake was on whoever installed the custom script. They probably didn't configure the auto-creation of the /var/run/fetchmail directory, something that would have been taken care of by an RPM package.

Ok but up until the weekend all was working just fine. The issues and errors started on the weekend when Linode did the migration.

Possibly, the reboot uncovered existing problems.

I had this happen to me, when I didn't handle a /var/run/ lock file for clamav. At the time, I wasn't aware that some directories and files are deleted/cleaned automatically, by default. Again this happened to me for /tmp files, due to tmpfiles.d, which is setup to clean them up in CentOS.

RPM packages automatically handle these situations, but custom files require the admin to do some extra work.

@IfThenElse:

Possibly, the reboot uncovered existing problems.

I had this happen to me, when I didn't handle a /var/run/ lock file for clamav. At the time, I wasn't aware that some directories and files are deleted/cleaned automatically, by default. Again this happened to me for /tmp files, due to tmpfiles.d, which is setup to clean them up in CentOS.

RPM packages automatically handle these situations, but custom files require the admin to do some extra work.

Ok, thanks for the reply. I'll forward this over to my server admin.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct