Hide Forgot
Description of problem: Siege from fedora gets "connection refused" when it tries to connect. Version-Release number of selected component (if applicable): siege-2.72-3.fc18.x86_64 How reproducible: siege -g http://172.27.1.175/ [error] socket: unable to connect sock.c:222: Connection refused [done] stracing shows: [pid 15007] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EINPROGRESS (Operation now in progress) [pid 15007] select(4, [3], [3], NULL, {30, 0}) = 2 (in [3], out [3], left {29, 999996}) [pid 15007] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 ECONNREFUSED (Connection refused) ( connect to 0.0.0.0 ? clearly wrong ) Works in upstream beta: ~/build/siege-2.73b6% ./src/siege -g http://172.27.1.175/ GET / HTTP/1.1 Host: 172.27.1.175 Accept: */* Accept-Encoding: User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.73b6) Connection: close
siege-2.74-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/siege-2.74-1.fc18
siege-2.74-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/siege-2.74-1.el6
Package siege-2.74-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing siege-2.74-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-2959/siege-2.74-1.fc18 then log in and leave karma (feedback).
siege-2.75-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/siege-2.75-1.fc18
siege-2.75-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/siege-2.75-1.el6
siege-2.75-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #6) > siege-2.75-1.fc18 has been pushed to the Fedora 18 stable repository. If > problems still persist, please make note of it in this bug report. Defect still present on my Fedora 18 system. [camoroso@f18dev ~]$ strace -f siege -c 1 -r 1 -f siege.url ... [pid 5923] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 [pid 5923] select(4, [3], [3], NULL, {30, 0}) = 1 (out [3], left {29, 999997}) [pid 5923] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EISCONN (Transport endpoint is already connected) [pid 5923] write(3, "GET /prova.txt HTTP/1.1\r\nHost: 1"..., 152) = 152 [pid 5923] select(4, [3], NULL, NULL, {30, 0}) = 1 (in [3], left {29, 999997}) [pid 5923] read(3, "HTTP/1.1 404 Not Found\r\nDate: Mo"..., 4096) = 397 .... [camoroso@f18dev ~]$ cat siege.url http://10.186.65.0/prova.txt [camoroso@f18dev ~]$ ifconfig p2p1 p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.186.16.198 netmask 255.255.240.0 broadcast 10.186.31.255 inet6 fe80::a00:27ff:fe6d:c9d7 prefixlen 64 scopeid 0x20<link> ether 08:00:27:6d:c9:d7 txqueuelen 1000 (Ethernet) RX packets 231092 bytes 24653772 (23.5 MiB) RX errors 0 dropped 213 overruns 0 frame 0 TX packets 286951 bytes 65660341 (62.6 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [camoroso@f18dev ~]$ rpm -q siege siege-2.75-1.fc18.x86_64 [camoroso@f18dev ~]$ uname -a Linux f18dev 3.8.2-206.fc18.x86_64 #1 SMP Fri Mar 8 15:03:34 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
(In reply to comment #7) > (In reply to comment #6) > > siege-2.75-1.fc18 has been pushed to the Fedora 18 stable repository. If > > problems still persist, please make note of it in this bug report. > > Defect still present on my Fedora 18 system. Looks OK to me. > [camoroso@f18dev ~]$ strace -f siege -c 1 -r 1 -f siege.url > ... > [pid 5923] read(3, "HTTP/1.1 404 Not Found\r\nDate: Mo"..., 4096) = 397 > .... The connection seems to be OK, giving a 404 error. > [camoroso@f18dev ~]$ cat siege.url > http://10.186.65.0/prova.txt What happens if you access this address with curl, wget or a web browser?
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > siege-2.75-1.fc18 has been pushed to the Fedora 18 stable repository. If > > > problems still persist, please make note of it in this bug report. > > > > Defect still present on my Fedora 18 system. > > Looks OK to me. > > > [camoroso@f18dev ~]$ strace -f siege -c 1 -r 1 -f siege.url > > ... > > [pid 5923] read(3, "HTTP/1.1 404 Not Found\r\nDate: Mo"..., 4096) = 397 > > .... > > The connection seems to be OK, giving a 404 error. That response 404 comes from Apache running on localhost (f18dev), not from requested host (10.186.65.0). > > > [camoroso@f18dev ~]$ cat siege.url > > http://10.186.65.0/prova.txt > > What happens if you access this address with curl, wget or a web browser? On host 10.186.65.0 the resource "prova.txt" is present and I get it with any other tool, e.g. GET, wget, etc. In other words, on my Fedora 18 installation, siege connects to localhost only, not to the host specified in the requested URL. I also tried it on Fedora 17 and Sabayon: On Fedora 17, siege gives same wrong behavior; on Sabayn insted it works as expected. (Sorry for my poor english)
More tests. Here I use two hosts: 1. f18dev IP: 10.186.16.198 OS: Fedora 18 x86_64 Kernel: 3.8.2-206.fc18.x86_64 Apache: httpd-2.4.3-15.fc18.x86_64 siege: siege-2.75-1.fc18.x86_64 2. vaio IP: 10.186.65.0 OS: Fedora 17 x86_64 Kernel: 3.7.9-104.fc17.x86_64 Apache: httpd-2.2.23-1.fc17.x86_64 =================== Request by GET (lwp-request): [camoroso@f18dev ~]$ GET http://vaio/prova.txt Hi, I'm prova.txt =================== Request by siege: [camoroso@f18dev ~]$ siege -c 1 -r 1 -g http://vaio/prova.txt GET /prova.txt HTTP/1.1 Host: vaio Accept: */* Accept-Encoding: User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.75) Connection: close HTTP/1.1 404 Not Found Date: Tue, 19 Mar 2013 08:05:00 GMT Server: Apache/2.4.3 (Fedora) PHP/5.4.12 Content-Length: 207 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL /prova.txt was not found on this server.</p> </body></html> [done] =================== Now, I copy and paste siege http request in a nc (netcat) connection: [camoroso@f18dev ~]$ nc vaio 80 GET /prova.txt HTTP/1.1 Host: vaio Accept: */* Accept-Encoding: User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.75) Connection: close HTTP/1.1 200 OK Date: Tue, 19 Mar 2013 08:04:52 GMT Server: Apache/2.2.23 (Fedora) Last-Modified: Tue, 19 Mar 2013 07:59:07 GMT ETag: "17fdaa-13-4d8427ade66e5" Accept-Ranges: bytes Content-Length: 19 Connection: close Content-Type: text/plain; charset=UTF-8 Hi, I'm prova.txt =================== Please, note the difference of Server http headers in last two responses: siege Server: Apache/2.4.3 (Fedora) PHP/5.4.12 nc Server: Apache/2.2.23 (Fedora) Hence, that means that the answer to siege comes from Apache running on f18dev and not from the one running on vaio. Further, as shown yesterday, I get following output tracing siege by strace: [camoroso@f18dev ~]$ strace -f siege -c 1 -r 1 -g http://vaio/prova.txt ... [pid 7220] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 [pid 7220] select(4, [3], [3], NULL, {30, 0}) = 1 (out [3], left {29, 999997}) [pid 7220] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EISCONN (Transport endpoint is already connected) [pid 7220] fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 ... [pid 7220] write(3, "GET /prova.txt HTTP/1.1\r\nHost: v"..., 141) = 141 [pid 7220] select(4, [3], NULL, NULL, {30, 0}) = 1 (in [3], left {29, 999998}) [pid 7220] read(3, "HTTP/1.1 404 Not Found\r\nDate: Tu"..., 4096) = 397 ...
That does look(In reply to comment #10) > More tests. Here I use two hosts That does look wrong indeed. I will try to somehow reproduce this. I see the 0.0.0.0 in strace too, but it still works for me. The only thing that comes to mind at the moment is that you use a .0 address for your vaio, which is usually a network address. I will try this on my machine to see if it makes a difference. If I can't find anything I will ping the siege author, maybe he has an idea.
(In reply to comment #11) > That does look(In reply to comment #10) > > More tests. Here I use two hosts > If I can't find anything I will ping the siege author, maybe he has an idea. Christof, I just built siege from source, version 2.78. Now it seems to work fine. [camoroso@f18dev bin]$ ./siege -c 1 -r 1 -g http://vaio/prova.txt GET /prova.txt HTTP/1.1 Host: vaio Accept: */* Accept-Encoding: User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.78) Connection: close HTTP/1.1 200 OK Date: Tue, 19 Mar 2013 13:21:52 GMT Server: Apache/2.2.23 (Fedora) Last-Modified: Tue, 19 Mar 2013 07:59:07 GMT ETag: "17fdaa-13-4d8427ade66e5" Accept-Ranges: bytes Content-Length: 19 Connection: close Content-Type: text/plain; charset=UTF-8 Hi, I'm prova.txt
(In reply to comment #12) > (In reply to comment #11) > > That does look(In reply to comment #10) > > > More tests. Here I use two hosts > > If I can't find anything I will ping the siege author, maybe he has an idea. > > Christof, I just built siege from source, version 2.78. Now it seems to work > fine. I have build a new RPM for f18. Could you test this? It is just on koji for now: http://koji.fedoraproject.org/koji/taskinfo?taskID=5143556
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > That does look(In reply to comment #10) > > > > More tests. Here I use two hosts > > > If I can't find anything I will ping the siege author, maybe he has an idea. > > > > Christof, I just built siege from source, version 2.78. Now it seems to work > > fine. > > I have build a new RPM for f18. Could you test this? It is just on koji for > now: http://koji.fedoraproject.org/koji/taskinfo?taskID=5143556 Done, but no good news. Test on siege built from sources [camoroso@f18dev bin]$ ./siege -c 1 -r 1 -g http://vaio/prova.txt GET /prova.txt HTTP/1.1 Host: vaio Accept: */* Accept-Encoding: User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.78) Connection: close HTTP/1.1 200 OK Date: Wed, 20 Mar 2013 09:06:21 GMT Server: Apache/2.2.23 (Fedora) Last-Modified: Tue, 19 Mar 2013 07:59:07 GMT ETag: "17fdaa-13-4d8427ade66e5" Accept-Ranges: bytes Content-Length: 19 Connection: close Content-Type: text/plain; charset=UTF-8 Hi, I'm prova.txt Test on siege from rpm [camoroso@f18dev bin]$ siege -c 1 -r 1 -g http://vaio/prova.txt [error] socket: -1871571200 connection refused.: Connection refused [done] [camoroso@f18dev bin]$ siege -V SIEGE 2.78 Copyright (C) 2013 by Jeffrey Fulmer, et al. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. PS: Today vaio IP is 10.186.65.23
(In reply to comment #14) > > [camoroso@f18dev bin]$ siege -c 1 -r 1 -g http://vaio/prova.txt > [error] socket: -1871571200 connection refused.: Connection refused > [done] > I am really lost here :-) As you can see from the spec file I am really not doing anything different from you compiling it on your machine. It is just configure & make, and there a no strange options in there: ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc/siege make -j5 It also works without problems for me. Maybe it is related to a dynamic library.
(In reply to comment #15) > (In reply to comment #14) > > > > [camoroso@f18dev bin]$ siege -c 1 -r 1 -g http://vaio/prova.txt > > [error] socket: -1871571200 connection refused.: Connection refused > > [done] > > > > I am really lost here :-) As you can see from the spec file I am really not > doing anything different from you compiling it on your machine. I did further analysis. Below you can see a summary. The critical point seems to be the call to the function gethostbyname_r(). In siege from rpm gethostbyname_r() translates "vaio" as "0". In siege from source, translation gives "390183434" -> "10.186.65.23". GDB shows it better. Rebuild using your configure command line (prefix = /home/camoroso/siege) [camoroso@f18dev siege]$ ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/home/camoroso/siege --exec-prefix=/home/camoroso/siege --bindir=/home/camoroso/siege/bin --sbindir=/home/camoroso/siege/sbin --sysconfdir=/home/camoroso/siege/etc --datadir=/home/camoroso/siege/share --includedir=/home/camoroso/siege/include --libdir=/home/camoroso/siege/lib64 --libexecdir=/home/camoroso/siege/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/home/camoroso/siege/share/man --infodir=/home/camoroso/siege/share/info --sysconfdir=/home/camoroso/siege/etc/siege [camoroso@f18dev siege]$ make [camoroso@f18dev siege]$ make install [camoroso@f18dev siege]$ ll totale 0 drwxrwxr-x 1 camoroso camoroso 80 21 mar 11.12 bin drwxrwxr-x 1 camoroso camoroso 10 21 mar 11.12 etc drwxrwxr-x 1 camoroso camoroso 6 21 mar 11.12 share drwxrwxr-x 1 camoroso camoroso 484 21 mar 11.11 siege-2.78 [camoroso@f18dev siege]$ cd bin [camoroso@f18dev bin]$ pwd /home/camoroso/siege/bin [camoroso@f18dev bin]$ export PATH=$PATH:`pwd` [camoroso@f18dev siege]$ echo $PATH /usr/...:/home/camoroso/siege/bin [camoroso@f18dev siege]$ siege -c 1 -r 1 -g http://vaio/prova.txt GET /prova.txt HTTP/1.1 Host: vaio Accept: */* Accept-Encoding: User-Agent: JoeDog/1.00 [en] (X11; I; Siege 2.78) Connection: close HTTP/1.1 200 OK Date: Thu, 21 Mar 2013 10:12:16 GMT Server: Apache/2.2.23 (Fedora) Last-Modified: Tue, 19 Mar 2013 07:59:07 GMT ETag: "17fdaa-13-4d8427ade66e5" Accept-Ranges: bytes Content-Length: 19 Connection: close Content-Type: text/plain; charset=UTF-8 Hi, I'm prova.txt ===================================================== STRACE on rpm: [camoroso@f18dev ~]$ strace -f siege -c 1 -r 1 -g http://vaio/prova.txt ... [pid 27951] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 ECONNREFUSED (Connection refused) [pid 27951] write(2, "[\33[1;33merror\33[0m] socket: 51964"..., 77Process 27952 attached <unfinished ...> [pid 27952] set_robust_list(0x7fa31e7919e0, 24) = 0 [pid 27952] rt_sigprocmask(SIG_BLOCK, [HUP INT TERM], [ESC[1;33merrorESC[0m] socket: 519644928 connection refused.: Connection refused ... STRACE on sources [camoroso@f18dev bin]$ strace -f /home/camoroso/siege/bin/siege -c 1 -r 1 -g http://vaio/prova.txt ... [pid 27848] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("10.186.65.23")}, 16) = 0 [pid 27848] select(4, [3], [3], NULL, {30, 0}) = 1 (out [3], left {29, 999995}) [pid 27848] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("10.186.65.23")}, 16) = -1 EISCONN (Transport endpoint is already connected) ... ===================================================== GDB analysis: Note value of hp-h_addr_list[0] and cli.sin_addr: in rpm it is 0; in source it is 390183434 -> 10.186.65.23 ===================================================== GDB on siege from rpm [camoroso@f18dev ~]$ gdb /usr/bin/siege ... Reading symbols from /usr/bin/siege...Reading symbols from /usr/lib/debug/usr/bin/siege.debug...done. done. (gdb) start -c 1 -r 1 -g http://vaio/prova.txt ... (gdb) b new_socket Breakpoint 2 at 0x40eca0: file sock.c, line 76. (gdb) cont Continuing. [New Thread 0x7ffff7fd9700 (LWP 28960)] [New Thread 0x7ffff77d8700 (LWP 28961)] [Switching to Thread 0x7ffff7fd9700 (LWP 28960)] Breakpoint 2, new_socket (C=C@entry=0x7ffff00008c0, hostparam=0x620580 "vaio", portparam=80) at sock.c:76 76 { (gdb) n ... 126 if((gethostbyname_r(hostparam, &hent, hbf, sizeof(hbf), &hp, &herrno) < 0)){ (gdb) p *((unsigned long *)hp->h_addr_list[0]) $3 = 0 ... 157 memcpy(&cli.sin_addr, hp->h_addr, hp->h_length); (gdb) n ... (gdb) p cli $4 = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"} (gdb) n 189 conn = connect(C->sock, (struct sockaddr *)&cli, sizeof(struct sockaddr_in)); (gdb) 190 pthread_testcancel(); (gdb) p conn $6 = -1 ===================================================== GDB on siege built from sources [camoroso@f18dev ~]$ cd siege/siege-2.78/src/ [camoroso@f18dev src]$ gdb ./siege ... Reading symbols from /home/camoroso/siege/siege-2.78/src/siege...done. (gdb) start -c 1 -r 1 -g http://vaio/prova.txt ... (gdb) b new_socket Breakpoint 2 at 0x40d890: file sock.c, line 76. (gdb) cont Continuing. [New Thread 0x7ffff7fdf700 (LWP 28978)] [New Thread 0x7ffff77de700 (LWP 28979)] [Switching to Thread 0x7ffff7fdf700 (LWP 28978)] Breakpoint 2, new_socket (C=C@entry=0x7ffff00008c0, hostparam=0x61c430 "vaio", portparam=80) at sock.c:76 76 { (gdb) n ... 126 if((gethostbyname_r(hostparam, &hent, hbf, sizeof(hbf), &hp, &herrno) < 0)){ (gdb) p *((unsigned long *)hp->h_addr_list[0]) $17 = 390183434 (gdb) n 157 memcpy(&cli.sin_addr, hp->h_addr, hp->h_length); (gdb) p cli $14 = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 390183434}, sin_zero = "\000\000\000\000\000\000\000"} (gdb) n 189 conn = connect(C->sock, (struct sockaddr *)&cli, sizeof(struct sockaddr_in)); (gdb) p conn $18 = 0 ===================================================== Note from man page of gethostbyname_r() [camoroso@vaio net]$ man gethostbyname_r ... DESCRIPTION The gethostbyname*() and gethostbyaddr*() functions are obsolete. Applications should use getaddrinfo(3) and getnameinfo(3) instead. ... ===================================================== >Maybe it is related to a dynamic library. RPM [camoroso@f18dev src]$ ldd /usr/bin/siege linux-vdso.so.1 => (0x00007fffff1fe000) libpthread.so.0 => /lib64/libpthread.so.0 (0x000000378a000000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003789c00000) libssl.so.10 => /lib64/libssl.so.10 (0x0000003404400000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x0000003403c00000) libc.so.6 => /lib64/libc.so.6 (0x0000003789800000) /lib64/ld-linux-x86-64.so.2 (0x0000003789400000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003403000000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003402c00000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x000000378fc00000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003403400000) libz.so.1 => /lib64/libz.so.1 (0x000000378ac00000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003403800000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003791000000) libresolv.so.2 => /lib64/libresolv.so.2 (0x000000378c800000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000378b000000) libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003402000000) libpcre.so.1 => /lib64/libpcre.so.1 (0x000000366e400000) Source [camoroso@f18dev src]$ ldd ~/siege/bin/siege linux-vdso.so.1 => (0x00007fffcaaa4000) libpthread.so.0 => /lib64/libpthread.so.0 (0x000000378a000000) libc.so.6 => /lib64/libc.so.6 (0x0000003789800000) /lib64/ld-linux-x86-64.so.2 (0x0000003789400000)
siege-2.75-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
sorry, that was closed by mistake
next try: siege 3.0.0 is has now been submitted to rawhide, f18, f19 and el6. Could you give it another try?
(In reply to comment #19) > next try: siege 3.0.0 is has now been submitted to rawhide, f18, f19 and > el6. Could you give it another try? I can't find that rpm. I found this: https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/Packages/s/siege-2.78-2.fc20.x86_64.rpm Could you post direct link to the right package?
(In reply to comment #20) > (In reply to comment #19) > > next try: siege 3.0.0 is has now been submitted to rawhide, f18, f19 and > > el6. Could you give it another try? > > I can't find that rpm. I found this: > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/ > Packages/s/siege-2.78-2.fc20.x86_64.rpm > > Could you post direct link to the right package? For rawhide you can find it here: http://kojipkgs.fedoraproject.org//packages/siege/3.0.0/2.fc20/x86_64/siege-3.0.0-2.fc20.x86_64.rpm For the others on the koji page: http://koji.fedoraproject.org/koji/packageinfo?packageID=3828
(In reply to comment #21) > (In reply to comment #20) > > (In reply to comment #19) > For the others on the koji page: > http://koji.fedoraproject.org/koji/packageinfo?packageID=3828 ========================== [camoroso@f18dev ~]$ siege -c 1 -r 1 -g http://vaio/prova.txt [error] socket: 982947584 connection refused.: Connection refused [done] [camoroso@f18dev ~]$ siege -V SIEGE 3.0.0 Copyright (C) 2013 by Jeffrey Fulmer, et al. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ========================== At this point I am convinced that the problem is in the build environment/context, not in the code.
(In reply to comment #22) > > At this point I am convinced that the problem is in the build > environment/context, not in the code. I agree. It would also help if I could reproduce this locally.
(In reply to comment #23) > (In reply to comment #22) > > > > At this point I am convinced that the problem is in the build > > environment/context, not in the code. > > I agree. It would also help if I could reproduce this locally. My env is a virtual machine on VirtualBox. $ rpm -q VirtualBox-4.2 VirtualBox-4.2-4.2.6_82870_el5-1 VM OS: Fedora 18 x86_64. [camoroso@f18dev ~]$ uname -a Linux f18dev 3.8.5-201.fc18.x86_64 #1 SMP Thu Mar 28 21:01:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [camoroso@f18dev ~]$ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) Ask me for any other info
I'm pretty sure this is a bug in siege. gethostbyname_r makes hp point at hent and hp->h_addr point at hbf both of which are automatic variables that have left scope by the time of the memcpy into cli.sin_addr (and this is undefined per section 6.2.4 of C99). I presume the differences people are to do with gcc versions or flags. But the code is broken. And moving hent and hbf up to function scope makes it work for me.
(In reply to comment #25) > I'm pretty sure this is a bug in siege. gethostbyname_r makes hp point at > hent and hp->h_addr point at hbf both of which are automatic variables that > have left scope by the time of the memcpy into cli.sin_addr (and this is > undefined per section 6.2.4 of C99). > > I presume the differences people are to do with gcc versions or flags. But > the code is broken. And moving hent and hbf up to function scope makes it > work for me. Thanks for your help Michael! Do you have a patch for this? Otherwise I can create one and send it to upstream too. I will try that later.
I wonder if this is related: http://freecode.com/projects/siege/releases/354453 "This release fixes a bug in which a host lookup failure could cause siege to erroneously send traffic to localhost."
Yes -- I sent a patch to the author. I'll attach it here too.
Created attachment 744355 [details] Patch to fix name resolution issue.
(In reply to comment #27) > I wonder if this is related: > http://freecode.com/projects/siege/releases/354453 > > "This release fixes a bug in which a host lookup failure could cause siege > to erroneously send traffic to localhost." Version 3.0.1-beta3 If you generate the rpm package in your build context, I'll try it on my F18 virtual machine.
(In reply to comment #30) > (In reply to comment #27) > > I wonder if this is related: > > http://freecode.com/projects/siege/releases/354453 > > > > "This release fixes a bug in which a host lookup failure could cause siege > > to erroneously send traffic to localhost." > > Version 3.0.1-beta3 > If you generate the rpm package in your build context, I'll try it on my F18 > virtual machine. beta4 is now available in rawhide. Here is the koji link: http://koji.fedoraproject.org/koji/taskinfo?taskID=5348395
(In reply to comment #31) > (In reply to comment #30) > > (In reply to comment #27) > > > I wonder if this is related: > > > http://freecode.com/projects/siege/releases/354453 > beta4 is now available in rawhide. Here is the koji link: > http://koji.fedoraproject.org/koji/taskinfo?taskID=5348395 :( [camoroso@f18dev ~]$ siege -c 1 -r 1 -g http://vaio/prova.txt [error] socket: -1665722624 unknown network error.: No route to host [done] [camoroso@f18dev ~]$ rpm -q siege siege-3.0.1-1.beta4.fc20.x86_64
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.