You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
builder.sign_file is hanging and never returning a manifest #42
I've created an api service for signing files using FastAPI. It's all running in a Docker container and works fine on my local machine. However, when I deploy it to a server, it is failing to sign files at the following line:
I'm not catching any errors, it just completely stalls, which means I have to restart the API service.
I thought it might be related to the server's ability to use the timestamp url, as it's on a University network and there are various restrictions in place. However, I have no problem reaching port 80 of timestamp.digicert.com from the server.
My best guess would be a timeout on something like a network call. Another thing we occasionally run into is temporary file access. Do you have any special constraints on where temp files are written?
Thanks @gpeacock. Looking at the network traffic, it appears to stall after the first few messages are exchanged with the timestamp server. Here's the section of output from tcpdump where those messages are exchanged. On my local machine it shows continued communication with the timestamp server after this point:
12:32:36.350009 IP 216.168.244.9.http > server.50204: Flags [S.], seq 2785666697, ack 3140477014, win 14600, options [mss 1460,nop,wscale 0,sackOK,TS val 1295602970 ecr 3630286823], length 0
12:32:36.350161 IP server.50204 > 216.168.244.9.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 3630286949 ecr 1295602970], length 0
12:32:36.350450 IP server.50204 > 216.168.244.9.http: Flags [P.], seq 1:182, ack 1, win 502, options [nop,nop,TS val 3630286949 ecr 1295602970], length 181: HTTP: POST / HTTP/1.1
12:32:36.350561 IP server.50204 > 216.168.244.9.http: Flags [P.], seq 182:258, ack 1, win 502, options [nop,nop,TS val 3630286949 ecr 1295602970], length 76: HTTP
12:32:36.350620 IP server.50204 > 216.168.244.9.http: Flags [P.], seq 258:263, ack 1, win 502, options [nop,nop,TS val 3630286949 ecr 1295602970], length 5: HTTP
12:32:36.477465 IP 216.168.244.9.http > server.50204: Flags [.], ack 263, win 14862, options [nop,nop,TS val 1295603096 ecr 3630286949], length 0
Which temporary file are you referring to? There shouldn't be any constraints that differ from the setup I'm running locally.
This issue is now more than one year old.
I'd suggest to try to update to latest SDK if possible (at time of writing v0.27.1). If the observed issue still happens, feel free to reopen the issue and we'll investigate further. Thanks!
Activity
gpeacock commentedon Oct 9, 2024
My best guess would be a timeout on something like a network call. Another thing we occasionally run into is temporary file access. Do you have any special constraints on where temp files are written?
di-rse commentedon Oct 9, 2024
Thanks @gpeacock. Looking at the network traffic, it appears to stall after the first few messages are exchanged with the timestamp server. Here's the section of output from tcpdump where those messages are exchanged. On my local machine it shows continued communication with the timestamp server after this point:
Which temporary file are you referring to? There shouldn't be any constraints that differ from the setup I'm running locally.
tmathern commentedon Oct 23, 2025
This issue is now more than one year old.
I'd suggest to try to update to latest SDK if possible (at time of writing v0.27.1). If the observed issue still happens, feel free to reopen the issue and we'll investigate further. Thanks!