Re: wget and WebKit?

[Tim Rühsen]

On 20.06.22 09:15, Josef Moellers wrote:

On 18.06.22 16:11, Tim Rühsen wrote:

Moin Josef,

Mooi'n Tim,

is it possible that 'wget' is linked to something else or is a different binary than expected ? Or maybe 'wget' is a script or alias ?

I had asked for straces and they show that "/usr/bin/wget/" is indeed the binary executed.

Because
a) webkit and wget have nothing in common

That was my impression, too. Thanks for confirming! However ... see below ...

b) That message you got seems not be originated in GNU Wget

Yes, it comes from WebKit (Source/WTF/wtf/posix/ThreadingPOSIX.cpp).



So we're now pursuing the "wget" -> "libproxy" -> "WebKit" trail.

I am also discussing this internally with people more familiar with proxy handling. "wget" is linked against libproxy and that may invoke WebKit.

Or is there some LD_PRELOAD magic involved ?


/* Hangup signal handler.  When wget receives SIGHUP or SIGUSR1, it
   will proceed operation as usual, trying to write into a log file.
   If that is impossible, the output will be turned off.  */

To change wget's behavior, you have to comment out this code:
```
#ifdef SIGUSR1
  if (sig == SIGUSR1)
    signal_name = "SIGUSR1";
#endif
```
and this code at L2094
```
#ifdef SIGUSR1
  signal (SIGUSR1, redirect_output_signal);
#endif
```

At least it explains


Maybe switch to SIGUSR2 (signal #12 on x86/ARM) via JSC_SIGNAL_FOR_GC !?

Regards, Tim

Does SUSE by any chance add their own patches to wget or any of the linked libraries ? Signal 10 is SIGUSR1, and wget sets a signal handler for it in src/main.c L122: "Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal"

OpenPGP_signature
Description: OpenPGP digital signature