similar to: Handling connection closes in (older) Sys::Virt

Hi all. I once tried to rsync around 100 GB (10 million files), but version 2.6.6 needed too much RAM and was too slow. Is one of the snapshots stable enough to try this again? Greetings Sven -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url :

-------- Original Message -------- Subject: rsync seem to be broken on sparc64 Date: 2016-06-27 23:43 From: alexmcwhirter at triadic.us To: debian-sparc at lists.debian.org I posted about this in the kernel lists a few months ago to no avail. I see it on gentoo as well with any kernel newer than 3.18. I came across this when using lxc on sparc64. The debian template uses rsync to move the

> -----Urspr?ngliche Nachricht----- > Von: Andre Lucas [SMTP:andre.lucas at dial.pipex.com] > Gesendet am: Freitag, 12. Mai 2000 16:37 > An: Bladt Norbert > Cc: 'Karsten Thygesen'; 'openssh-unix-dev at mindrot.org'; > 'carl at bl.echidna.id.au' > Betreff: Re: Patch: OpenSSH 2.1.0 under Solaris 8, Solaris 7 and > other systems, too > > Well

Hi! I ran into a problem with programs exec:ed by print/acroread8 picking up Linux libraries and thus failed to run. This includes the print program in the print dialogue and the browser configured in edit/preferences/internet. The reason is that the acroread launch script sets LD_LIBRARY_PATH which is propagated to its childs. See this PR:

Hello. I'm having serious issues with ext3; any insight would be greatly appreciated: _____ Overview: I believe ext3 is supposed to be recoverable in the case of a power failure by replaying the log. However, on two separate computers (running different operatings systems too), this has been everything but the case. _____ Specifics: Sometimes, my kernel will hard-freeze and I'll

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 ??

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

xend crashes at startup with following stack trace: ... File "/usr/lib64/python/xen/xend/XendPIF.py", line 68, in linux_get_phy_ifaces phy_ifaces.append((name, int(mtu), bridged_mac)) UnboundLocalError: local variable ''bridged_mac'' referenced before assignment The simple patch attached below prevent the crash, and allow xend to start normally. It seems the crash

(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

Hi. I don''t know if this one is known, but I can''t recall seeing anything about it. If it is old news I apologize. I discovered a bug in the inetd that comes with NetKit-B-0-08 and older. If a single SYN is sent to port 13 of the server, inetd will die of Broken Pipe: write(3, "Sun Jan 12 21:50:35 1997\r\n", 26) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) ---

Every few days I find that dovecot auth is using all my CPU. This is from dovecot 2.2.13, I've just upgraded to 2.2.18 strace -r -p 17956 output: Process 17956 attached 0.000000 lseek(19, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) 0.000057 getsockname(19, {sa_family=AF_LOCAL, NULL}, [2]) = 0 0.000043 epoll_ctl(15, EPOLL_CTL_ADD, 19, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP,

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

I've been hacking with parallel package for some time and built a parallel processing framework with it. However, although very rarely, I did notice "ignoring SIGPIPE signal" error every now and then. After a deep dig into the source code, I think I found something worth noticing. In short, wring to pipe in the C function mc_exit(SEXP sRes) may cause a SIGPIPE. Code from

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

Hi all, I think it's a bug, when call virDomainGetState after "service libvirtd stop", I receive signal SIGPIPE. I want to know how to avoid this problem? And Other interfaces will also encounter this problem？ Below the bt information: Below some information about my hypervisor: root@ubuntu-05:/datapool/zhuohf# virsh -v 3.4.0 root@ubuntu-05:/datapool/zhuohf# qemu-x86_64 -version

I have problem with smbmount and losetup working together. The data seems to be corrupted. Description: I have an NT4 server with a share. On my linux box i use smbmount to mount the share. I have created a big file on the share and use losetup to configure a loop-back device on which i try to create/use a filesystem. It seems to work at first with ext2fs, but after copying some files to the

https://bugzilla.mindrot.org/show_bug.cgi?id=2071 Bug ID: 2071 Summary: sshd closes stderr but not stdout when child process exits Classification: Unclassified Product: Portable OpenSSH Version: 6.1p1 Hardware: All OS: All Status: NEW Severity: normal Priority: P5

https://bugzilla.mindrot.org/show_bug.cgi?id=2655 Bug ID: 2655 Summary: AuthorizedKeysCommand with large output can deadlock Product: Portable OpenSSH Version: 7.2p2 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: sshd Assignee: unassigned-bugs at

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:

Have read the latest code, but I still don't understand why mc_exit needs to write zero on exit. If a child closes its pipe, parent will know that on next select. Best, Yijiang Tomas Kalibera <tomas.kalibera at gmail.com> ?2019?5?20??? ??10:52??? > > This issue has already been addressed in 76462 (R-devel) and also ported > to R-patched. In fact rmChild() is used in