Created attachment 343579 [details] Proposed patch Description of problem: The fix for bug #140983 makes system calls interruptible with SIGALRM. But if that signal is triggered during a writev() (which can happen when sriting so a slow console via serial), syslog will print a message "/dev/console: Interrupted system call" and stop logging to console. Version-Release number of selected component (if applicable): sysklogd-1.4.1-26_EL How reproducible: Just once in the customer's environment. But reproducer provided by our partner. Steps to Reproduce: 1. Connect the serial console to system. 2. Edit /etc/syslog.conf as follows to have syslogd write many messages to /dev/console. --- [/etc/syslog.conf] *.debug /dev/console --- 3. Execute the following example program to log messages continuously to syslog. 8<-------8<-------8<-------8<-------8<------- #include<stdio.h> #include<syslog.h> int main(void) { int i; for(i=0;;i++) syslog(LOG_DEBUG,"test--%d",i); return 0; } 8<-------8<-------8<-------8<-------8<------- Actual Results: syslogd does not write any messages to /dev/console. Expected Results: syslogd writes any messages to /dev/console. Additional info: I could not reproduce the issue internally using the technique described, however based on the description, I believe the following attached patch might help with the issue. A test package has been given to our partner, awaiting test results.
Comment on attachment 343579 [details] Proposed patch Patch is causing more bad than good.
Created attachment 346544 [details] Proposed patch Same patch as previous, except that it repeats the latest writev() call instead of returning.
Created attachment 346869 [details] Proposed patch Third version. Now if writev() cannot write all the data to the file descriptor, the iovec is properly updated and another attempt to writev() is done. This way no data is lost.
Created attachment 347437 [details] Proposed patch A different approach to the problem. This patch simply just reschedules the ALARM signal prior to log the messages. So if a writev() is blocked and an alarm occurs, the log is closed and syslog keeps going on. But by rescheduling the alarm just before calling writev() it virtually avoids the signal to be triggered during the writev() by accident. This approach is preferred by our customer.
Created attachment 347440 [details] Proposed patch Well, another patch, hopefully the last one. This patch is actually a mix of my two previous patches. - Reschedule the ALARM just prior to call writev() to make avoid a signal coming up during the writev() - Still recompute iovec when writev() could not write all data to avoid messages being half written to the log.
Please be so kind and add a few key words to the technical note of this bugzilla entry using the following structure: Cause: Consequence: Fix: Result: For details, see: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: Consequence: Fix: Result:
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,7 +1,12 @@ Cause: +SIGALRM signal is triggered during a writev() (which can happen when writing so a slow console via serial) Consequence: +syslogd stops writing messages to /dev/console. Fix: +Reschedule the ALARM just prior to call writev(). +Recompute iovec when writev() could not write all data to avoid messages being half written to the log -Result:+Result: +syslogd keeps writing messages to /dev/console.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0225.html