search for: start_serv

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

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

...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 { EventMachine.start_server("192.168.2.252",6200,TickServer) do |conn| conn.hello_world end } Where conn holds the instance of the class TickServer. So, I want to mock this class, so that i don''t have to create an actual socket connection. Please look in the code, carefully. most of the methods in...

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 _...

...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 (m...

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

...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 -> ../python/show_engine.py start_server.py -> ../python/start_server.py stop_server.py -> ../python/stop_server.py However, at the destination the .. is missing. for example the link "../python/compile_plan.py" becomes "python/compile_plan.py" at the destination. Gary Aviv This e-mail and any attachments ar...

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 set am_server = 1 explicitly or drop the connection with an error if the client doesn't supply --server. Matt

...a(text) thread_pool.defer(text) do |text| scrap_and_store_text(text) end end Please consult backgroundrb documentation for more information about this. By default the thread pool is of size 20. 5. Wrote examples on, how to use "connect" and "start_server" methods from backgroundrb workers. Again, consult documentation for it. Lets try/run it for a while and it will be released as 1.0 . -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http...

...uffered () from /proc/22367/exe #3 0x00007fa36509bd33 in readfd () from /proc/22367/exe #4 0x00007fa36509c0f6 in read_msg_fd () from /proc/22367/exe #5 0x00007fa3650834d5 in generate_files () from /proc/22367/exe #6 0x00007fa36508e29c in do_recv () from /proc/22367/exe #7 0x00007fa36508ed82 in start_server () from /proc/22367/exe #8 0x00007fa36508fc55 in child_main () from /proc/22367/exe #9 0x00007fa3650a943e in local_child () from /proc/22367/exe #10 0x00007fa36508cb45 in do_cmd () from /proc/22367/exe #11 0x00007fa36508f53f in main () from /proc/22367/exe $ gstack 22368 #0 0x0000000000a24ad3...

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 +++++++++++++++++++++++-----...

...g, but what I''m really trying to test here is how to communicate between the two workers, not whether the connection_worker is alive. So I''m wondering what the best way to communicate between these workers is. I took a look at the advanced stuff and I think that maybe connect and start_server could work for me, but the documentation on them leaves me confused as to how to actually implement them. Any suggestions or help would be much appreciated. Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/atta...

...c:744 #4 0x4a2d76 in receive_xattr /home/raj/rsync/rsync/xattrs.c:835 #5 0x40beac in recv_file_entry /home/raj/rsync/rsync/flist.c:1108 #6 0x415bee in recv_file_list /home/raj/rsync/rsync/flist.c:2476 #7 0x454eaa in do_server_recv /home/raj/rsync/rsync/main.c:1036 #8 0x4556f4 in start_server /home/raj/rsync/rsync/main.c:1115 #9 0x4b20f2 in rsync_module /home/raj/rsync/rsync/clientserver.c:1007 #10 0x4b2b11 in start_daemon /home/raj/rsync/rsync/clientserver.c:1135 #11 0x48f636 in start_accept_loop /home/raj/rsync/rsync/socket.c:618 #12 0x4b32d2 in daemon_main /home/raj...

...5236c in _select () from /usr/lib/libc.so.1 #2 0x00025ee8 in writefd_unbuffered () #3 0x00026f4c in io_multiplex_write () #4 0x0001ce6c in rwrite () #5 0x0001cfcc in rprintf () #6 0x00012ae0 in recv_generator () #7 0x000139fc in generate_files () #8 0x00019528 in do_recv () #9 0x000197f4 in start_server () #10 0x0002fec4 in start_daemon () #11 0x00030088 in daemon_main () #12 0x0001a52c in main () server child process: #0 0xff19db44 in _poll () from /usr/lib/libc.so.1 #1 0xff15236c in _select () from /usr/lib/libc.so.1 #2 0x000251e0 in read_timeout () #3 0x00025cc4 in readfd_unbuffered ()...

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

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

...#2 0x0000000000426cf4 in match_sums (f=1, s=0x192d220, buf=0x192d1e0, len=214748364800) at match.c:398 #3 0x000000000041a175 in send_files (f_in=0, f_out=1) at sender.c:391 #4 0x0000000000423620 in do_server_sender (f_in=0, f_out=1, argc=1, argv=0x18da238) at main.c:822 #5 0x0000000000423f1f in start_server (f_in=0, f_out=1, argc=2, argv=0x18da230) at main.c:1089 #6 0x0000000000425282 in main (argc=2, argv=0x18da230) at main.c:1630 (gdb) quit -- a number of seconds later -- root at st1:~# gdb /usr/bin/rsync 4942 --snip-- 0x0000000000426972 in hash_search (f=1, s=0x192d220, buf=0x192d1e0, len=214748...

...01", N=4) at io.c:1144 #4 0x0000000000424dcf in read_msg_fd () at io.c:342 #5 0x000000000040fd1f in generate_files (f_out=1, local_name=<value optimized out>) at generator.c:2089 #6 0x00000000004190b4 in do_recv (f_in=0, f_out=1, local_name=0x0) at main.c:848 #7 0x00000000004198a3 in start_server (f_in=0, f_out=1, argc=1, argv=<value optimized out>) at main.c:958 #8 0x000000000041af15 in child_main (argc=490388736, argv=0xffffffffffffffff) at main.c:965 #9 0x0000000000430b2e in local_child (argc=2, argv=0x7fff1d3aff00, f_in=0x7fff1d3b2f2c, f_out=0x7fff1d3b2f28, child_main=0x41af00...