Ticket #207 (new defect)

Opened 13 years ago

Last modified 12 years ago

wget processes started by GLI keep running on GLI crash, and more wget tasks

Reported by: oranfry Owned by: ak19
Priority: moderate Milestone: Greenstone 2 wishlist
Component: GLI Severity: major
Keywords: wget Cc:


If you start a web download, and then GLI crashes (which it is apt to do if something goes wrong with the download), the wget process which is handling the download stays alive and runs in the background. This bug is especially troubling when this orphaned wget process has been set to follow links a to a ridiculous depth, like 10, which pretty much covers the whole internet. In this case, the wget process silently attempts to download the whole internet over a connection which might be pay-per-byte. This bug could attract 'GLI cost me hundreds with my ISP!' complaints so should be looked at promptly.

Change History

Changed 12 years ago by kjdon

  • severity set to major
  • milestone set to Release 2.81

Changed 12 years ago by davidb

  • owner changed from nobody to or

Changed 12 years ago by davidb

  • owner changed from or to oranfry

Changed 12 years ago by oranfry

  • status changed from new to assigned

Changed 12 years ago by davidb

  • owner changed from oranfry to ak19
  • status changed from assigned to new

Proposed solution: Java sends "I'm OK" socket message every 20 secs. Perl decides to quit wget if it doesn't get message after, say, 1 min.

Changed 12 years ago by ak19

  • keywords wget added
  • summary changed from wget processes started by GLI keep running on GLI crash to wget processes started by GLI keep running on GLI crash, and more wget tasks

Also need to do further wget/download work: 1. Ensure that when GLI is naturally exited and if downloads are running (wget or other downloads), these processes are terminated. 2. Test that when CTRL-C is sent to GLI (a.o.t. the downloadfrom.pl script which handles these already), any running downloads are terminated along with the perl script that launched them. Test both on Windows and Linux. 3. May need Ctrl-C handlers for other Downloads (SRW, Z3950) so that on sending the SIGINT (ctrl-C) to the downloadfrom.pl perl script, any such downloads which are open are also terminated. See step 4 for possible solution. 4. Solution proposed by Max/Oran/Dr Bainbridge to the problem of Wget downloads still running on GLI crash: - Every 20 or 40s, GLI sends "I'm OK" message/ping to perl code. Perl code checks that every 20s/40s it got this message from GLI. Otherwise (GLI is not working for some reason, possibly it crashed), 10s beyond this, it will kill any launched wget and terminate. This may solve step 3 above in one go.

Changed 12 years ago by ak19

The remaining tasks are listed above.


1. Wget downloads get terminated when running the downloadfrom.pl script from the command line on both Linux and Windows, achieved by using a handler for SIGINT (ctrl-c).

2. On both Linux and Windows, Wget now gets terminated when the user presses the download panel's close button. While sig handlers were sufficient for this on Linux, this was not possible on Windows. Sockets (using perl's IO::Sockets and IO::Select) are now used for GLI to communicate that it is time to terminate wget to the perl script. Note that Perl's IO::Select on the STDIN and other file handles do not work on Windows.

Changed 12 years ago by davidb

  • milestone changed from Release 2.81 to Release 2.82

GLI quiting due to internal factors now stable. Crashing due to external factors is a different prospect. This ticket is (with the solution of Java pinging the perl code through a socket to say it's OK) now reassigned to the 2.82 release.

Changed 12 years ago by kjdon

  • milestone changed from Release 2.82 to Release 2.83
Note: See TracTickets for help on using tickets.