Is This A Bug In CentOS-7 BackupPC?

Home » CentOS » Is This A Bug In CentOS-7 BackupPC?
CentOS 4 Comments

When I try to start BackupPC with “sudo systemctl restart BackupPC”
on my CentOS-7 server (running kernel 3.10.0-229.14.1.el7.x86_64)
I get the following error in /var/log/BackupPC/LOG

2015-09-26 13:58:14 Reading hosts file
2015-09-26 13:58:14 unix bind() failed: No such file or directory

This message occurs in the Perl script /usr/share/BackupPC/bin/BackupPC :

my $sockFile = “/var/run/BackupPC/BackupPC.sock”;
unlink($sockFile);
if ( !bind(SERVER_UNIX, sockaddr_un($sockFile)) ) {
print(LOG $bpc->timeStamp, “unix bind() failed: $!\n”);
exit(1);
}

As far as I can see (I’m no guru) this is trying to open a unix socket with the name /var/run/BackupPC/BackupPC.sock .

There is no directory /var/run/BackupPC/ on my server. When I create this, setting BackupPC.apache as owner, and run “sudo systemctl restart BackupPC”
I see in /var/log/BackupPC/LOG that BackupPC has (at long last) started

4 thoughts on - Is This A Bug In CentOS-7 BackupPC?

  • Seems a packaging issue ? From where is your rpm for BackupPC coming ?
    /var/run on EL7 is in fact pointing to /run , which is tmpfs, so packages aren’t supposed to drop something there directly, or that will be gone anyway next time your restart the machine. Workaround for those not-yet-fixed-for-systemd-packages : man tmpfiles.d (that will create/maintain those)

    –

  • Fabian Arrotin wrote:

    From epel .

    I don’t really understand this. The perl script wants to create /var/run/BackupPC/BackupPC.sock which it seems it cannot do unless /var/run/BackupPC/ exists. If as you say this disappears on re-booting, I don’t see how this program could work.

  • Seems like a packaging bug in EPEL. Fedora does this (semi-)right, by dropping down an /etc/tmpfiles.d/BackupPC.conf, which instantiates the
    /var/run/BackupPC directory as 0755 root:BackupPC.

    Looking at the epel7 specfile, I see:

    # tmpfiles.d & systemd support in all supported Fedora now, but not RHEL
    %if 0%{?fedora}
    %global _with_tmpfilesd 1
    %global _with_systemd 1
    %endif

    and then later:

    %if 0%{?_with_tmpfilesd}
    install -d $RPM_BUILD_ROOT/%{_sysconfdir}/tmpfiles.d install -p -m 0644 %{SOURCE6}
    $RPM_BUILD_ROOT/%{_sysconfdir}/tmpfiles.d/%{name}.conf
    %endif

    and

    %if 0%{?_with_tmpfilesd}
    %config(noreplace) %{_sysconfdir}/tmpfiles.d/%{name}.conf
    %endif

    Of course, CentOS7 (and RHEL7) supports tmpfiles.d, in fact, may system services require it, such as cups, samba, pam, etc. I’m not sure why the BackupPC package installs it in /etc/tmpfiles.d instead of /usr/lib/tmpfiles.d, probably because the person who made the package isn’t very systemd-saavy.

    The contents of the /etc/tmpfiles.d/BackupPC.conf file looks like this:

    D /var/run/BackupPC 0775 root BackupPC –

    If you create that file, you’ll get the /var/run/BackupPC file when you start up. I suggest filing a bug against the EPEL package if you want to get it fixed there.

  • Jonathan Billings wrote:

    Thanks very much for the explanation and suggestion. I’ve created that file, and will see what happens next time I re-boot.