Dan Nicolaescu <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > > > Dan Nicolaescu <[EMAIL PROTECTED]> wrote: > > ... > > > I have installed Fedora 8 on another 32bit x86 system, and the problem > > > appears there too. > > > > > > (I moved /etc/csh* out of the way, used a freshly created account that > > > uses /bin/tcsh. I also deleted all the ~/.* files) > > > > > > I straced the mingetty process corresponding to VT 1, and logged on > > > there. > > > The only mention of SIGPIPE is this: > > > > > > 4549 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0 ... > Maybe it is done in some library? Here's the part of the strace log that > includes the SIGPIPE handling
I've tracked it down. mingetty exec's /bin/login, which calls pam stuff, which in turn uses libdbus. And that is the culprit: ./dbus/dbus-sysdeps-unix.c-_dbus_disable_sigpipe (void) ./dbus/dbus-sysdeps-unix.c-{ ./dbus/dbus-sysdeps-unix.c: signal (SIGPIPE, SIG_IGN); ./dbus/dbus-sysdeps-unix.c-} That function is called by default. The change that introduced this behavior dates back to 2003: http://www.redhat.com/archives/message-bus-list/2003-February/msg00001.html Perhaps dbus-the-daemon needs this behavior, but the library code must not ignore SIGPIPE. Since it's a library, it shouldn't modify process state at all, but if portability dictates that it ignore SIGPIPE temporarily, it should be careful to restore the preceding handler asap. The dbus library can avoid the problem altogether when a system supports sendto's new POSIX-specified MSG_NOSIGNAL flag (just test #ifdef MSG_NOSIGNAL): MSG_NOSIGNAL Requests not to send SIGPIPE on errors on stream oriented sockets when the other end breaks the connection. The EPIPE error is still returned. I'm filing a bug report to the dbus folks. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils