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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 26/09/15 16:16, Timothy Murphy wrote:
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
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 The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
Fabian Arrotin wrote:
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
Seems a packaging issue ? From where is your rpm for backuppc coming ?
From epel .
/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)
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.
On Sat, Sep 26, 2015 at 08:12:40PM +0100, Timothy Murphy wrote:
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:
On Sat, Sep 26, 2015 at 08:12:40PM +0100, Timothy Murphy wrote:
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.
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.
Thanks very much for the explanation and suggestion. I've created that file, and will see what happens next time I re-boot.
-
Fabian Arrotin -
Jonathan Billings -
Timothy Murphy