siege can exceed its -t limit

[jimrobinson]

I've never seen siege do this before (and I've been running it a lot lately), but I thought it was interesting that it apparently is possible for siege to keep going after its -t <limit> has been reached:

$ ps -ef | grep [s]iege
jimr     14315 14097  0 07:24 pts/0    00:00:00 docker run --name jimr_siege --rm -it -v /home/jimr:/data jimrobinson/bombard:latest siege -q -f /data/1300.urls.txt -b -t 10m
jimr     14352 14334 99 07:24 pts/0    00:57:33 siege -q -f /data/1300.urls.txt -b -t 10m
$ date
Tue  2 Jun 07:45:16 PDT 2020

This was siege 4.0.5 running inside a ubuntu:16.04 docker container (built using https://github.com/jimrobinson/bombard, available via https://hub.docker.com/jimrobinson/bombard)

I eventually used docker stop on the job and it spat the following out before exiting:

[error] Address resolution failed at sock.c:158 with the following error:: No such file or directory
[error] Name or service not known: No such file or directory
[error] Address resolution failed at sock.c:158 with the following error:: No such file or directory
[error] Name or service not known: No such file or directory

As far as I can determine it wasn't running out of sockets (netstat -nt wasn't showing a lot of TIME_LIMIT files).

The siege configuration is mostly the default, the differences being

turning off show-logfile, disabling json_output, and specifying a default logfile and file.

verbose = true
color = on
quiet = false
json_output = false
show-logfile = false
logging = false
logfile = /data/siege.log
gmethod = HEAD
parser = true
nofollow = ad.doubleclick.net
nofollow = pagead2.googlesyndication.com
nofollow = ads.pubsqrd.com
nofollow = ib.adnxs.com
limit = 255
protocol = HTTP/1.1
chunked = true
cache = false
connection = close
concurrent = 25
file = /data/urls.txt
delay = 0.0
internet = false
benchmark = false
accept-encoding = gzip, deflate
url-escaping = true
unique = true

[JoeDog]

If you want more precision, then use -r, --reps=NUM with -t, --time=NUM a signal is fired when the timer expires but if a thread is in a system call, it won't respond until after it completes.

…

On Tue, Jun 2, 2020 at 10:59 AM James A. Robinson ***@***.***> wrote: I've never seen siege do this before (and I've been running it a *lot* lately), but I thought it was interesting that it apparently is possible for siege to keep going after its -t <limit> has been reached: $ ps -ef | grep [s]iege jimr 14315 14097 0 07:24 pts/0 00:00:00 docker run --name jimr_siege --rm -it -v /home/jimr:/data jimrobinson/bombard:latest siege -q -f /data/1300.urls.txt -b -t 10m jimr 14352 14334 99 07:24 pts/0 00:57:33 siege -q -f /data/1300.urls.txt -b -t 10m $ date Tue 2 Jun 07:45:16 PDT 2020 This was siege 4.0.5 running inside a ubuntu:16.04 docker container (built using https://github.com/jimrobinson/bombard, available via https://hub.docker.com/jimrobinson/bombard) I eventually used docker stop on the job and it spat the following out before exiting: [error] Address resolution failed at sock.c:158 with the following error:: No such file or directory [error] Name or service not known: No such file or directory [error] Address resolution failed at sock.c:158 with the following error:: No such file or directory [error] Name or service not known: No such file or directory As far as I can determine it wasn't running out of sockets (netstat -nt wasn't showing a lot of TIME_LIMIT files). The siege configuration is mostly the default, the differences being turning off show-logfile, disabling json_output, and specifying a default logfile and file. verbose = true color = on quiet = false json_output = false show-logfile = false logging = false logfile = /data/siege.log gmethod = HEAD parser = true nofollow = ad.doubleclick.net nofollow = pagead2.googlesyndication.com nofollow = ads.pubsqrd.com nofollow = ib.adnxs.com limit = 255 protocol = HTTP/1.1 chunked = true cache = false connection = close concurrent = 25 file = /data/urls.txt delay = 0.0 internet = false benchmark = false accept-encoding = gzip, deflate url-escaping = true unique = true — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#178>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJRHZXZHZ6MIW67YD4ROELRUUHWHANCNFSM4NQZZAVQ> .

[jimrobinson]

Thanks, a missed signal would explain it.