Description of problem: I recently upgraded to BackupPC-3.2.1-1.fc15.x86_64, which apparently now uses /var/run/BackupPC. That directory didn't exist on my machine, so it would silently fail to start. The LOG file didn't provide much help, but strace revealed the problem. I don't know much about rpm, but it seems like a script should be run that creates the directory. (Maybe the script does do that and just failed on my machine for some reason; I upgraded about a month ago, and I just rebooted today.) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I can reproduce. Same problem, same solution.
Ok, I did a "rpm -ql BackupPC" which does show a "/var/run/BackupPC" which explains why it works when I first install, however, it appears something is removing that directory. This is all very strange. In reviewing the spec file I came across the following section: %if 0%{?_with_systemd} %{_unitdir}/backuppc.service %config(noreplace) %{_sysconfdir}/tmpfiles.d/%{name}.conf %else %attr(0755,root,root) %{_initrddir}/backuppc %dir %attr(0775,backuppc,backuppc) %{_localstatedir}/run/%{name} %endif Should the line that grabs /var/run/BackupPC be placed outside of the if conditional or is that directory only needed with sysvinit and not systemd? Richard
(In reply to comment #2) > Ok, I did a "rpm -ql BackupPC" which does show a "/var/run/BackupPC" which > explains why it works when I first install, however, it appears something is > removing that directory. This is all very strange. I keyed on tmpfiles.d being in > F15, but it appears that it starts in F15. I'll have to change around the conditionals a bit. I guess I need to check when systemd was introduced too - make sure I didn't get that wrong. I'll try to get a test build out this weekend.
Well of course systemd is available in F15 but I figured that BackupPC was sticking with the old system since from what I understand (from reading the devel list) no one is supposed to switch from old to new within a release, so the next chance to switch to a systemd based install will be F16, which is how the conditionals in the spec file seem to be setup. (i.e. fedora > 15) Is that correct?
And therein lies the problem. Originally when I started working on the spec, I was going to bring systemd support into F15. But then as you mentioned, the next chance became F16. When I added tmpfiles.d support, I used the same conditional - it really goes hand and hand with systemd. So what I'll have to do is include tmpfiles.d support back to F15 and leave systemd support where it is.
Please try this scratch build and see if it resolves the problem for F15. Thanks
http://koji.fedoraproject.org/koji/taskinfo?taskID=3270229
So far so good, it hasn't stopped running. I was able to cause an SEAlert though. From the http interface I clicked on "Log" and got this: SELinux is preventing /usr/bin/perl from read access on the file /var/log/BackupPC/LOG. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that perl should be allowed read access on the LOG file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep BackupPC_Admin. /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:var_log_t:s0 Target Objects /var/log/BackupPC/LOG [ file ] Source BackupPC_Admin. Source Path /usr/bin/perl Port <Unknown> Host hobbes.localdomain Source RPM Packages perl-5.12.4-160.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.16-35.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name hobbes.localdomain Platform Linux hobbes.localdomain 2.6.40-4.fc15.x86_64 #1 SMP Fri Jul 29 18:46:53 UTC 2011 x86_64 x86_64 Alert Count 1 First Seen Sun 14 Aug 2011 07:56:07 PM CDT Last Seen Sun 14 Aug 2011 07:56:07 PM CDT Local ID 2e6c75fa-7d5b-4d1f-ba0e-090631c18bc3 Raw Audit Messages type=AVC msg=audit(1313369767.589:820): avc: denied { read } for pid=4272 comm="BackupPC_Admin." name="LOG" dev=dm-3 ino=11010082 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file type=AVC msg=audit(1313369767.589:820): avc: denied { open } for pid=4272 comm="BackupPC_Admin." name="LOG" dev=dm-3 ino=11010082 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file type=SYSCALL msg=audit(1313369767.589:820): arch=x86_64 syscall=open success=yes exit=ESRCH a0=2118610 a1=0 a2=1b6 a3=7fe11b306e30 items=0 ppid=15379 pid=4272 auid=4294967295 uid=48 gid=489 euid=489 suid=489 fsuid=489 egid=489 sgid=489 fsgid=489 tty=(none) ses=4294967295 comm=BackupPC_Admin. exe=/usr/bin/perl subj=system_u:system_r:httpd_t:s0 key=(null) Hash: BackupPC_Admin.,httpd_t,var_log_t,file,read audit2allow #============= httpd_t ============== allow httpd_t var_log_t:file { read open }; audit2allow -R #============= httpd_t ============== allow httpd_t var_log_t:file { read open }; Instead of following the default directions for audit2allow which greps through the entire log, I only pulled the last (and appropriate) entry. Audit2allow then gives: """ module backuppc 1.0; require { type var_log_t; type httpd_t; class file open; } #============= httpd_t ============== allow httpd_t var_log_t:file open; """ I think this is what needs to be added to the selinux context in the spec. Richard
Richard please open a separate bug for this. It looks like we need a new label for BackupPC and to allow apache to read it.
Same problem here. Your BackupPC.conf file from your scratch build has 2 problems. At first mistake (backukppc instead of backuppc) and modes (775) should be before UID/GID. Here is a patch: --- /tmp/BackupPC.conf 2011-08-13 06:15:24.000000000 +0200 +++ BackupPC.conf 2011-08-16 16:28:09.000000000 +0200 @@ -1 +1 @@ -D /var/run/BackupPC backukppc backuppc 775 - +D /var/run/BackupPC 775 backuppc backuppc - With this file I need to run: systemd-tmpfiles --create and then backuppc starts well. I am not sure, if you need to start systemd-tmpfiles manually after update of package or it will be run automatically.
I think you mean BackupPC.tmpfiles.
(In reply to comment #11) > I think you mean BackupPC.tmpfiles. No, I mean /etc/tmpfiles.d/BackupPC.conf from x86_64 package, but looks like it's BackupPC.tmpfiles in src.rpm. :-) Please, update this file and make an testing update in bodhi. Thanks.
Here is another scratch build. http://koji.fedoraproject.org/koji/taskinfo?taskID=3287658 (In reply to comment #10) > I am not sure, if you need to start systemd-tmpfiles manually after update of > package or it will be run automatically. This page: http://fedoraproject.org/wiki/Packaging:Tmpfiles.d says "tmpfiles.d is a service provided by both systemd and upstart in Fedora 15 and later for managing temporary files and directories." and "Configuring tmpfiles.d just involves dropping a file into %{_sysconfdir}/tmpfiles.d/ that tells the init system what directories need to be created." I don't have a system with tmpfiles.d to confirm this on, but if you can check that functionality I would appreciate it. I will address the selinux errors in the bug that it was reported (bz 730704)
(In reply to comment #13) > Here is another scratch build. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=3287658 Package looks well. I can test it on a production system, if you make an testing update in bodhi. > > I am not sure, if you need to start systemd-tmpfiles manually after update of > > package or it will be run automatically. > > This page: http://fedoraproject.org/wiki/Packaging:Tmpfiles.d says "tmpfiles.d > is a service provided by both systemd and upstart in Fedora 15 and later for > managing temporary files and directories." and "Configuring tmpfiles.d just > involves dropping a file into %{_sysconfdir}/tmpfiles.d/ that tells the init > system what directories need to be created." I think they don't need to process tmpfiles restart for normal packages. If somebody updates fc15 package from fc14- (or older) there is no need to restart tmpfiles. In old system (fc14-) tmpfiles are created on real filesystem, after restart they will be created using tmpfiles.d. But your current package has missing tmpfile, so an user should restart their system after update or at least reload tmpfiles creation. May be you can suggest reboot using bodhi, even if it's not necessary.
BackupPC-3.2.1-4.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/BackupPC-3.2.1-4.fc16
(In reply to comment #15) > BackupPC-3.2.1-4.fc16 has been submitted as an update for Fedora 16. > https://admin.fedoraproject.org/updates/BackupPC-3.2.1-4.fc16 Will the package push in Fedora 15 ?
Package BackupPC-3.2.1-4.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing BackupPC-3.2.1-4.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/BackupPC-3.2.1-4.fc16 then log in and leave karma (feedback).
(In reply to comment #16) > Will the package push in Fedora 15 ? Package is available in updates-testing repository for F-15 (see: https://admin.fedoraproject.org/updates/BackupPC-3.2.1-4.fc15). Missing /var/run/BackupPC bug seems to be solved with that build.
BackupPC-3.2.1-4.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
The problem still exists for me in Fedora 16. I'm using: ~]$ rpm -q BackupPC BackupPC-3.2.1-6.fc16.x86_64 /var/run/BackupPC does not exist after package install. So, the backuppc daemon failed to start with: 2011-11-17 22:16:10 unix bind() failed: No such file or directory After creating /var/run/BackupPC, the daemon starts.
(In reply to comment #20) > The problem still exists for me in Fedora 16. What is the contents of /etc/tmpfiles.d/BackupPC.conf ?
~]$ cat /etc/tmpfiles.d/BackupPC.conf D /var/run/BackupPC 0775 root backuppc -
Please add a new bug and we can debug further.
The missing /var/run/BackupPC directory is still a problem with 3.2.1-10 on Fedora 17. I upgraded from the previous version of BackupPC last night, and found that I had to manually create /var/run/BackuPC after the upgrade in order for BackuPC to work.
Yes, I recently attempted to fedup to F18 which was a disaster. After complete reinstall I had to add this directory before BackupPC would start.
NAME=Fedora VERSION="17 (Beefy Miracle)" ID=fedora VERSION_ID=17 PRETTY_NAME="Fedora 17 (Beefy Miracle)" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:fedoraproject:fedora:17" BackupPC-3.2.1-10.fc17.i686 there was no /etc/tmpfiles.d/BackupPC.conf file I made the /var/run/BackupPC dir - did not fix my issue. I rebooted. The dir /var/run/BackupPC was gone when I was back up. I made /etc/tmpfiles.d/BackupPC.conf by hand according to Comment 22. I rebooted again. The dir was made and the service worked.
I would add a new bug if I knew how. I tried to clone this one as a start, but I did not get far.
Missing directories may not related to the current bug, but to bz #896626 Try BackupPC-3.2.1-11.fc17 from testing repositories; this release should fix your issue.
(In reply to comment #26) > NAME=Fedora > VERSION="17 (Beefy Miracle)" > ID=fedora > VERSION_ID=17 > PRETTY_NAME="Fedora 17 (Beefy Miracle)" > ANSI_COLOR="0;34" > CPE_NAME="cpe:/o:fedoraproject:fedora:17" > > BackupPC-3.2.1-10.fc17.i686 > > there was no /etc/tmpfiles.d/BackupPC.conf file > > I made the /var/run/BackupPC dir - did not fix my issue. I rebooted. The dir > /var/run/BackupPC was gone when I was back up. I made > /etc/tmpfiles.d/BackupPC.conf by hand according to Comment 22. I rebooted > again. The dir was made and the service worked. I concur. Creating /var/run/BackupPC was only a temporary fix; it was gone when I rebooted.
You might want to start adding NamedFileTransrules to your policy. optional_policy(` gen_require(` attribute unconfined_domain_type; ') files_pid_filetrans(unconfined_domain_type, backup_var_run_t, dir, "BackupPC") ') THis would cause all confined domains to create /run/BackupPC with the proper label.