FIFO / pipe destination problem
This may end up being something really easy that I am missing, but I have been struggling with it for a couple days. Googling the problem has yet to review any fruitful answers. I am trying to pass messages to MySQL via the pipe() function. I am working with syslog-ng 1.6.5-6 compiled from source for Fedora Core 3. I have setup a FIFO in the filesystem as follows: [root@furw tmp]# mkfifo mysql.pipe [root@furw tmp]# chmod 0600 mysql.pipe [root@furw tmp]# ls -al ... drwxrwxrwt 24 root root 4096 Feb 14 17:38 . drwxr-xr-x 23 root root 4096 Feb 11 16:00 .. prw------- 1 root root 0 Feb 14 17:38 mysql.pipe ... I then created my syslog-ng.conf file: ... options { sync (0); time_reopen (10); log_fifo_size (1000); long_hostnames (off); use_dns (no); use_fqdn (no); create_dirs (no); keep_hostname (yes); }; source src { unix-stream ("/dev/log"); internal(); udp(ip(0.0.0.0) port(514)); }; destination d_mysql { pipe("/tmp/mysql.pipe" template("INSERT INTO logs (host, facility, priority, level, tag, date, time, program, msg) VALUES ( '$HOST', '$FACILITY', '$PRIORITY', '$LEVEL', '$TAG', '$YEAR-$MONTH-$DAY', '$HOUR:$MIN:$SEC', '$PROGRAM', '$MSG' );\n") template-escape(yes)); }; destination d_cons { file("/dev/console"); }; destination d_mesg { file("/var/log/messages"); }; destination d_auth { file("/var/log/secure"); }; destination d_mail { file("/var/log/maillog" sync(10)); }; destination d_spol { file("/var/log/spooler"); }; destination d_boot { file("/var/log/boot.log"); }; destination d_cron { file("/var/log/cron"); }; destination d_mlal { usertty("*"); }; filter f_filter1 { facility(kern); }; filter f_filter2 { level(info..emerg) and not facility(mail,authpriv,cron); }; filter f_filter3 { facility(authpriv); }; filter f_filter4 { facility(mail); }; filter f_filter5 { level(emerg); }; filter f_filter6 { facility(uucp) or (facility(news) and level(crit..emerg)); }; filter f_filter7 { facility(local7); }; filter f_filter8 { facility(cron); }; #log { source(src); filter(f_filter1); destination(d_cons); }; log { source(src); filter(f_filter2); destination(d_mysql); }; log { source(src); filter(f_filter2); destination(d_mesg); }; log { source(src); filter(f_filter3); destination(d_auth); }; log { source(src); filter(f_filter4); destination(d_mail); }; log { source(src); filter(f_filter5); destination(d_mlal); }; log { source(src); filter(f_filter6); destination(d_spol); }; log { source(src); filter(f_filter7); destination(d_boot); }; log { source(src); filter(f_filter8); destination(d_cron); }; ... Then I started syslog-ng and received the following errors in /var/log/messages: ... Feb 14 16:21:59 furw syslog-ng[21895]: Cannot open file /var/run/mysql.pipe for writing (Permission denied) ... When I run an strace on the file, I get the following: ... uname({sys="Linux", node="furw", ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=130, ...}) = 0 open("/tmp/mysql.pipe", O_RDWR|O_NONBLOCK|O_NOCTTY|O_LARGEFILE) = -1 EACCES (Permission denied) chown32("/tmp/mysql.pipe", 0, 0) = -1 EACCES (Permission denied) chmod("/tmp/mysql.pipe", 0600) = -1 EACCES (Permission denied) time(NULL) = 1108422581 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=130, ...}) = 0 ... Does anyone have an idea of why syslog-ng cannot read my pipe? I am open to ideas... -Matt
On Mon, 2005-02-14 at 16:50, Howell, Matt wrote:
When I run an strace on the file, I get the following:
... uname({sys="Linux", node="furw", ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=130, ...}) = 0 open("/tmp/mysql.pipe", O_RDWR|O_NONBLOCK|O_NOCTTY|O_LARGEFILE) = -1 EACCES (Permission denied) chown32("/tmp/mysql.pipe", 0, 0) = -1 EACCES (Permission denied) chmod("/tmp/mysql.pipe", 0600) = -1 EACCES (Permission denied) time(NULL) = 1108422581 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=130, ...}) = 0 ...
Does anyone have an idea of why syslog-ng cannot read my pipe? I am open to ideas...
Are you running with selinux? If so type "dmesg" to get the error and use it to adjust your policy. [Or setenforce 0 to prove that it is indeed the problem]
participants (2)
-
Howell, Matt
-
Mike Tremaine