Opened 16 years ago

Last modified 15 years ago

#207 new defect

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 (9)

comment:1 by kjdon, 16 years ago

Milestone: Release 2.81
Severity: major

comment:2 by davidb, 15 years ago

Owner: changed from nobody to or

comment:3 by davidb, 15 years ago

Owner: changed from or to oranfry

comment:4 by oranfry, 15 years ago

Status: newassigned

comment:5 by davidb, 15 years ago

Owner: changed from oranfry to ak19
Status: assignednew

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.

comment:6 by ak19, 15 years ago

Keywords: wget added
Summary: wget processes started by GLI keep running on GLI crashwget 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 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 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.

comment:7 by ak19, 15 years ago

The remaining tasks are listed above.


  1. Wget downloads get terminated when running the script from the command line on both Linux and Windows, achieved by using a handler for SIGINT (ctrl-c).
  1. 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.

comment:8 by davidb, 15 years ago

Milestone: Release 2.81Release 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.

comment:9 by kjdon, 15 years ago

Milestone: Release 2.82Release 2.83
Note: See TracTickets for help on using tickets.