Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: SIGINT vs. SIGTERM?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Jeffrey Walton via curl-users <curl-users_at_lists.haxx.se>
Date: Sun, 25 Aug 2024 21:21:30 -0400
On Sun, Aug 25, 2024 at 7:21 PM Paul Gilmartin via curl-users
<curl-users_at_lists.haxx.se> wrote:
>
> Don't consider this a problem report; I've worked around it.
>
> On 8/25/24 15:20, Daniel Stenberg wrote:
>
> > On Sun, 25 Aug 2024, Paul Gilmartin via curl-users wrote:
> >
> >> Running curl from a script I attempt to terminate a long download.
> >> kill -INT curl has no effect
> >> kill -TERM curl terminates curl.
> >>
> >> Does curl trap SIGINT for some special behavior, leaving the default SIGTERM?
> >
> > SIGINT is the signal that hitting ctrl-c in a terminal sends to the application like when aborting a slow transfer. I use that frequently with curl and I have never seen or experienced a problem with that. So no, curl does not ignore SIGINT.
> > .
> 800 $ uname -msv
> Darwin Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 PDT 2024; root:xnu-10063.141.2~1/RELEASE_X86_64 x86_64
> 801 $ curl --version
> curl 8.9.1 (x86_64-apple-darwin23.4.0) libcurl/8.9.1 OpenSSL/3.3.1 (SecureTransport) zlib/1.2.12 brotli/1.1.0 zstd/1.5.6 libidn2/2.3.7 libssh2/1.11.0 nghttp2/1.61.0 librtmp/2.3
> Release-Date: 2024-07-31
>
> curl from the command line works as you describe.
> I have curl buried in scripts with complicated options.
> In my top script trapped a signal and killed the curl
> process. SIGTERM worked; SIGINT didn't.
>
> Hard to reproduce.
Look at your signal handlers. They are _not_ MT-safe. If you try to do
some things in them -- like log a printf("signal received: %d", sig);
-- then you are in undefined behavior territory. I've seen signal
handlers hang because of things like logging using printf. If you want
to log in your signal handler, then call write(2) directly.
Jeff
Date: Sun, 25 Aug 2024 21:21:30 -0400
On Sun, Aug 25, 2024 at 7:21 PM Paul Gilmartin via curl-users
<curl-users_at_lists.haxx.se> wrote:
>
> Don't consider this a problem report; I've worked around it.
>
> On 8/25/24 15:20, Daniel Stenberg wrote:
>
> > On Sun, 25 Aug 2024, Paul Gilmartin via curl-users wrote:
> >
> >> Running curl from a script I attempt to terminate a long download.
> >> kill -INT curl has no effect
> >> kill -TERM curl terminates curl.
> >>
> >> Does curl trap SIGINT for some special behavior, leaving the default SIGTERM?
> >
> > SIGINT is the signal that hitting ctrl-c in a terminal sends to the application like when aborting a slow transfer. I use that frequently with curl and I have never seen or experienced a problem with that. So no, curl does not ignore SIGINT.
> > .
> 800 $ uname -msv
> Darwin Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 PDT 2024; root:xnu-10063.141.2~1/RELEASE_X86_64 x86_64
> 801 $ curl --version
> curl 8.9.1 (x86_64-apple-darwin23.4.0) libcurl/8.9.1 OpenSSL/3.3.1 (SecureTransport) zlib/1.2.12 brotli/1.1.0 zstd/1.5.6 libidn2/2.3.7 libssh2/1.11.0 nghttp2/1.61.0 librtmp/2.3
> Release-Date: 2024-07-31
>
> curl from the command line works as you describe.
> I have curl buried in scripts with complicated options.
> In my top script trapped a signal and killed the curl
> process. SIGTERM worked; SIGINT didn't.
>
> Hard to reproduce.
Look at your signal handlers. They are _not_ MT-safe. If you try to do
some things in them -- like log a printf("signal received: %d", sig);
-- then you are in undefined behavior territory. I've seen signal
handlers hang because of things like logging using printf. If you want
to log in your signal handler, then call write(2) directly.
Jeff
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-08-26