search for: start_serving

Hi, On windows, get_peername works both with connections obtained via start_server, and connections obtained via connect. On linux, get_peername seems to only work with connections obtained via start_server. (I''m using svn HEAD.) I''m wondering which is the intended behavior? (I realize get_peername is less useful for connections obtained via connect, since one should already

...NULL); > > Wait. Does this even work? It works in the same way as nbdkit_absolute_path() did: when calling it on a relative path, nbdkit_absolute_path() will prepend $PWD to it, while the new nbdkit_realpath() will do something similar. At least the usages that I changed are called before start_serving() (and thus before fork_into_background()), so I think there should be no issue wrt paths. Did I miss anything? -- Pino Toscano

Ok, here is the class, I want to Unit Test, its part of a large app and is based on EventMachine library. I want to mock the class TickServer ( i.e not stub it) . Since in actual scenario, you can''t do this on this class: @server = TickServer.new # will toss an exception at your face you must initialize the server like this: EventMachine.run {

I am using eventmachine 0.8.1 on windows XP and am having very odd problems. This snippet of code gives the error that follows it. class EchoServer def receive_data data puts data send_data ">>>you sent: #{data}" if data =~ /quit/i puts "quitting" close_connection EventMachine::stop_event_loop end end end

...05577156b9646 in poll (__timeout=-1, __nfds=2, __fds=<optimized out>) at /usr/include/bits/poll2.h:46 #2 check_sockets_and_quit_fd (nr_socks=1, socks=0x55771f18c2e0) at sockets.c:466 #3 accept_incoming_connections (socks=0x55771f18c2e0, nr_socks=1) at sockets.c:494 #4 0x00005577156ac6ac in start_serving () at main.c:914 #5 main (argc=<optimized out>, argv=0x7ffd0bcb15d8) at main.c:685 Thread 1 (Thread 0x7f12b820e700 (LWP 231469)): #0 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007f12b86b28d9 in __GI_abort () at abort.c:79 #2 0x00007f12b86b27a9 in __as...

...clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fabc002ca40 (LWP 3955770)): #0 0x00007fabc06a3b02 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00005583f90d6dbf in accept_incoming_connections (socks=0x5584020bf010, nr_socks=1) at sockets.c:501 #2 0x00005583f90ca441 in start_serving () at main.c:936 #3 main (argc=<optimized out>, argv=<optimized out>) at main.c:702 The stack trace of [1] at the hang is: Thread 2 (Thread 0x7f30ac822700 (LWP 3955798)): #0 0x00007f30b32a384c in recv () from /lib64/libpthread.so.0 #1 0x00007f30b3342c8f in _gnutls_stream_read (ms=0...

...call this too late, then it is not; it would be trivial to rewrite it so that we manually prepend something cached from when the program started, so that this is then conceptually correct no matter when we change directories later. > > At least the usages that I changed are called before start_serving() > (and thus before fork_into_background()), so I think there should be no > issue wrt paths. Oh. Hmm. Interesting observation, that .config and .config_complete finish PRIOR to start_serving() (and makes sense, too, as if we're going to diagnose any errors, printing to stderr is a L...

I am running latest rsync version 2.6.8 on both ends. The receiver is a daemon. When I transfer a symbolic link like this: /tmp/rsync -av /opt/iat/IaT3.1.1/bin/* uxgary::root/opt/iat/IaT3.1/bin building file list ... done compile_plan.py -> ../python/compile_plan.py iat_status -> ../python/iat_status.py load_iat_xml.py -> ../python/load_iat_xml.py show_engine.py ->

Dear rsync people (particularly Wayne), I noticed that an rsync daemon counts on the client sending a --server option so that am_server gets set to 1. If the client doesn't supply this option, am_server remains 0 but the daemon runs start_server anyway. This is potentially dangerous and might lead to a security hole, although I haven't found one yet. I suggest that the daemon either

Hi Folks, Well, Yesterday I pushed some more updates that I was cooking since last couple of days. Here is a brief list: 1. Results from worker stays even after a worker dies. 2. You can ask backgroundrb to store status objects in memcache cluster now. by default its stored in master process memory, but I have introduced an option to allow it to be stored in a memcache cluster:

https://bugzilla.samba.org/show_bug.cgi?id=5701 Summary: deadlock on local rsyncing, bisected to commit f303b749f2843433c9acd8218a4b9096d0d1bb8d Product: rsync Version: 3.1.0 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P3 Component: core AssignedTo:

Eric: Did you want to take this one any further? It might be one that we save for > 1.18: https://www.redhat.com/archives/libguestfs/2020-February/thread.html#00206 Another thing I've been thinking about for some time is splitting .config_complete into .config_complete + .get_ready (new name TBD). At the moment .config_complete is both the place where we finish processing config, and

...in.patch" >From aaee5182e0578f0bab0a0b09bce1a2410eda93db Mon Sep 17 00:00:00 2001 From: "Richard W.M. Jones" <rjones@redhat.com> Date: Sat, 22 Feb 2020 10:54:56 +0000 Subject: [PATCH 1/2] server: Check parameters in main (). Unclear why we were checking these parameters in start_serving, except because that's historically how it was always done. Also move some serving-related calls into start_serving. While this slightly changes the order of operations in some corner cases, it's essentially neutral code refactoring. --- server/main.c | 46 +++++++++++++++++++++++--------...

Hi everyone, I have two workers, a connection_worker and an interface_worker, that I want to be able to call methods on each other. Initially I thought I could do this: connection_worker def alive? return true end end interface_worker def test_connection if MiddleMan.worker(:connection_worker).alive?(true) return true end end end Obviously this is a somewhat contrived

https://bugzilla.samba.org/show_bug.cgi?id=13112 Bug ID: 13112 Summary: receive_xattr heap overread with non null terminated name and xattr filter Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core

Greetings and salutations, rsync users. I have a problem. I'm hoping that someone out there could perhaps provide a hand. I've been trying to transfer large amounts of data (lots of data, lots of files) via rsync over an encrypted TCP tunnel, but I seem to be continually getting hangs in the transfers -- things will go along for a bit, and then just come to a screetching halt. There

...truct backend *, struct connection *conn, int readonly); int (*prepare) (struct backend *, struct connection *conn, void *handle, int readonly); diff --git a/server/main.c b/server/main.c index 5623149..935d422 100644 --- a/server/main.c +++ b/server/main.c @@ -857,6 +857,7 @@ start_serving (void) for (i = 0; i < nr_socks; ++i) socks[i] = FIRST_SOCKET_ACTIVATION_FD + i; change_user (); + backend->ready_to_serve (backend); write_pidfile (); accept_incoming_connections (socks, nr_socks); free_listening_sockets (socks, nr_socks); /* also closes th...

v1 was here: https://www.redhat.com/archives/libguestfs/2019-November/msg00003.html This version depends on: https://www.redhat.com/archives/libguestfs/2019-November/msg00004.html and this series: https://www.redhat.com/archives/libguestfs/2019-November/msg00009.html The delta has been reduced slightly because of changes made possible by cleaning up and fixing the quit path in nbdkit. It's

https://bugzilla.samba.org/show_bug.cgi?id=10518 Summary: rsync hangs (100% cpu) Product: rsync Version: 3.1.1 Platform: All OS/Version: Linux Status: NEW Severity: critical Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: syzop at vulnscan.org QAContact:

I've noticed the 3.0.0pre versions sometimes hanging while doing a local copy (through dirvish). This time a had a binary with debugging symbols, so I could do gdb backtraces. This is the result: # ps -fe | grep rsync root 3712 3710 0 02:04 ? 00:00:03 rsync -vrltH --delete -pgo --stats -D --numeric-ids -x --exclude-from=/backup/0/oudeserver/laatste/exclude