Red Hat Bugzilla – Bug 169006
Syslogd not able to write to ext3 Logical Volume. Get sync error
Last modified: 2007-11-30 17:07:20 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050729 Fedora/1.0.6-3.EL (CK-IBM) Firefox/1.0.6 Description of problem: A new logical volume was created and mounted as /var/log. Prior to this syslog was able to write logs to the /var filesystem which is a logical volume on the same physical volume as the /var/log lv. Syslogd is stopped and the new lv mounted . After syslogd is restarted no logs are created. Running strace on the syslogd daemon shows the following errors. writev(1, [{"Sep 21 16:48:00", 15}, {" ", 1}, {"9.182.116.73", 12}, {" ", 1}, {"Sep 21 2005 16:53:09 inpix01 : %"..., 184}, {"\r\n", 2}], 6) = 215 fsync(1) = -1 EINVAL (Invalid argument) Version-Release number of selected component (if applicable): sysklogd-1.4.1-26_EL and lvm2-2.01.08-1.0.RHEL4 How reproducible: Always Steps to Reproduce: 1.stop syslogd 2.mount new lv 3.start syslogd Actual Results: No logs created Expected Results: Logs being written to files in /var/log Additional info: I created another lv on the same server and had the same problem
I tried copying all the files on /var to the filesystem I used as /var/log and mounted it as /var. I then ran strace on syslogd and saw the following problem. I confirmed that root could create the file from the commandline and that the syslogd process was running as root. Please Note that this issue was raised as a Security bug as without logging we cannot fullfill our security conditions. set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ff5aa0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xb7ff6000, 38344) = 0 getpid() = 3366 chdir("/") = 0 brk(0) = 0x9366000 brk(0x9387000) = 0x9387000 open("/var/run/syslogd.pid", O_RDONLY) = -1 EACCES (Permission denied) rt_sigaction(SIGTERM, {0xc28238, [TERM], SA_RESTORER|SA_RESTART, 0x9fb8c8}, {SIG_DFL}, 8) = 0
You have SELinux in Enforcing mode, no ? If NOT, then you did not copy /var/log with 'cp -rfp...' / 'tar -cp...' to preserve access modes - doing so should fix the problem: # ( cd /var; tar -cpf - . ) | ( cd /new_var; tar -xpf - ) If so - SELinux is enabled in Enforcing mode - then, with your new /var filesystem mounted, you need to do, as root: # setenforce 0 # restorecon -R /var # setenforce 1