Bug 169006 - Syslogd not able to write to ext3 Logical Volume. Get sync error
Summary: Syslogd not able to write to ext3 Logical Volume. Get sync error
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: sysklogd
Version: 4.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jason Vas Dias
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-09-22 01:31 UTC by Phillip Short
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-22 17:50:53 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Phillip Short 2005-09-22 01:31:07 UTC
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

Comment 1 Phillip Short 2005-09-22 12:23:26 UTC
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


Comment 2 Jason Vas Dias 2005-09-22 17:50:53 UTC
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 


Note You need to log in before you can comment on or make changes to this bug.