similar to: SOLARIS:SIGPIPE in nmbd (PR#8723)

Hello, The attached patch should fix Debian bug #128632 (http://bugs.debian.org/128632). This bug happened because if an error occurred in writefd_unbuffered (such as the remote end closing the socket), it would call rprintf, which would call io_multiplexing_write, which would in turn call writefd_unbuffered, which would then just sit in a loop trying to write to the broken socket. Also, we

On Fri, Aug 04, 2023 at 03:46:47PM +0300, Arseniy Krasnov wrote: >Hi Stefano, > >On 02.08.2023 10:46, Stefano Garzarella wrote: >> On Tue, Aug 01, 2023 at 05:17:26PM +0300, Arseniy Krasnov wrote: >>> POSIX requires to send SIGPIPE on write to SOCK_STREAM socket which was >>> shutdowned with SHUT_WR flag or its peer was shutdowned with SHUT_RD >>> flag.

On Mon, Aug 14, 2023 at 10:46:05PM +0300, Arseniy Krasnov wrote: > > >On 04.08.2023 17:28, Stefano Garzarella wrote: >> On Fri, Aug 04, 2023 at 03:46:47PM +0300, Arseniy Krasnov wrote: >>> Hi Stefano, >>> >>> On 02.08.2023 10:46, Stefano Garzarella wrote: >>>> On Tue, Aug 01, 2023 at 05:17:26PM +0300, Arseniy Krasnov wrote: >>>>>

On Fri, Aug 04, 2023 at 05:34:20PM +0300, Arseniy Krasnov wrote: > > >On 04.08.2023 17:28, Stefano Garzarella wrote: >> On Fri, Aug 04, 2023 at 03:46:47PM +0300, Arseniy Krasnov wrote: >>> Hi Stefano, >>> >>> On 02.08.2023 10:46, Stefano Garzarella wrote: >>>> On Tue, Aug 01, 2023 at 05:17:26PM +0300, Arseniy Krasnov wrote: >>>>>

On Mon, Aug 14, 2023 at 10:40:17PM +0300, Arseniy Krasnov wrote: > > >On 04.08.2023 18:02, Stefano Garzarella wrote: >> On Fri, Aug 04, 2023 at 05:34:20PM +0300, Arseniy Krasnov wrote: >>> >>> >>> On 04.08.2023 17:28, Stefano Garzarella wrote: >>>> On Fri, Aug 04, 2023 at 03:46:47PM +0300, Arseniy Krasnov wrote: >>>>> Hi Stefano,

While nbdkit itself must run with SIGPIPE ignored, many applications expect to inherit SIGPIPE in the default state. What's worse, POSIX states that a non-interactive shell script cannot use 'trap' to undo an inherited SIG_IGN on SIGPIPE. I have seen several bug reports over the years of something that works for a developer but fails under a CI environment, where the root cause was

Hi. I'm writing an article on network backups, and instead of using my old ssh1 software, I decided to go with openssh all the way. I got the hang of the openssh way of doing protocol 2 public key authentication, but ssh is failing to terminate when a pipe is broken. I am ssh-ing to a remote host and doing a cat or zcat of a dump file, then on the localhost, I'm using restore to extract

Dear OpenSSH gurus! ;-) I recently upgraded from "OpenSSH 2.1.1p4" to "OpenSSH 2.3.0p1" on my Linux 2.2.17 box with OpenSSL 0.9.5a (RedHat 7.0). According to the "ChangeLog", there was a change in SIGPIPE handling: | 20000930 | [...] | - (djm) Ignore SIGPIPEs from serverloop to child. Fixes crashes with | very short lived X connections. Bug report from

Hello, I've got problems with Samba 3.6.0 up to 3.6.6. Forked smbd processes are closing unexpectedly and sometimes smbd server exits. (In Samba 3.5.16 everything works). When invoke smbd from gdb and turn off SIGPIPE passing (by command "handle SIGPIPE nostop nopass") everything works fine. I found out that SigBlk flag of forked smbd processes in /proc/*/status is:

(I am not on the rsync mailing list, so if you send a response to this message to the list, please be sure to CC me.) I first reported this bug go Red Hat in <URL:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65350>. If you run rsync with a subshell through ssh.com's ssh and sshd and then kill the client with ctrl-C, the rsync server process running on the remote machine grows

On Sat, Aug 26, 2023 at 08:58:59PM +0300, Arseniy Krasnov wrote: >POSIX requires to send SIGPIPE on write to SOCK_STREAM socket which was >shutdowned with SHUT_WR flag or its peer was shutdowned with SHUT_RD >flag. Also we must not send SIGPIPE if MSG_NOSIGNAL flag is set. > >Signed-off-by: Arseniy Krasnov <avkrasnov at salutedevices.com> >--- > net/vmw_vsock/af_vsock.c

Hello, I have several systems which I recently updated with yum -y update to all the latest packages. These systems use yum-priorities and use the CentOS (priority 1) EPEL (priority 5) and rpmforge (priority 10) repositories. After the updates, dhcpd stopped working with a SIGPIPE error which occurs shortly after it attempts to fork into the background. I worked around that problem by building

Hi R-devel, tcltk devel, and sqldf devel, The transcript below shows how loading the tcl/tk library in under R causes subprocesses to ignore SIGPIPE. I am including the developer of the (wonderful) sqldf package since it requires tcltk and you might like to make this dependence optional to the user (at least until this is fixed in tcltk). Am I mistaken in calling this a 'bug'? Any

http://bugzilla.mindrot.org/show_bug.cgi?id=85 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|markus at openbsd.org |openssh-unix-dev at mindrot.org Status|ASSIGNED |NEW ------- Additional Comments From markus at

Dear list I don't know whether this is the right place to post this message. If not, please redirect me to the proper place. i have a Perl application on Linux that uses R (V2.9.0) through the Perl-R interface. basically, the application performs statistical analysis using R, and displays the R output (JPG image of the particular analysis) to the user. in general, this works fine. but i

Hi Benjamin, you cannot pipe to echo, since it does not read from stdin. echo just echos is first arg, i.e. echo /dev/stdin > /dev/null will echo the string "/dev/stdin"to /dev/stdout, which is redirected to /dev/null. Try p <- pipe("cat > /dev/null", open = "w") instead. Regards, Andreas 2019-12-06 02:46 GMT+01:00 Benjamin Tyner<btyner at

Not sure if this is a bug, so posting here first. If I run: ?? cnt <- 0L ?? while (TRUE) { ? ? ?? cnt <- cnt + 1L ? ? ?? p <- pipe("echo /dev/stdin > /dev/null", open = "w") ? ? ?? writeLines("foobar", p) ? ? ?? tryCatch(close(p), error = function(e) { print(cnt); stop(e)}) ?? } then once cnt gets to around 650, it fails with: ?? [1] 654 ??

Andreas, How right you are! Still, I find it curious that in the context of the while(TRUE) loop, I am allowed to do this 653 times, with failure on the 654th attempt. Perhaps there is something asynchronous going on? If I eliminate the looping, it does indeed fail (as expected) on the first attempt to close the pipe. Regards Ben On 12/6/19 2:04 AM, Andreas Kersting wrote: > Hi

I've been running rsync-2.4.2 with an old patch of mine for some time for backup purposes. Due to the recent remote bug, I thought it was time to upgrade, even if the host was behind a firewall. So I dug up the old patch (2.5.2 version attached), that I think I sent ages ago to this list as well. It does the following: (1) Firstly, the only sensible way to run something as

Hi, This also has been discussed in SSHSCI's SSH context. All SSH versions (both SSHSCI and OpenSSH) derive value for DISPLAY variable from `uname -n`. The problem is that the returned value is not necessarily resolvable to a valid IP number which in turn might cause a failure. To make it fool-proof I suggest to set DISPLAY to the interface's address the user has reached the system in