Bug #76611 ndb_restore doesn't handle SIGHUP
Submitted: 7 Apr 2015 13:41 Modified: 8 Apr 2015 11:57
Reporter: Edward Mackenzie Email Updates:
Status: Verified Impact on me:
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S4 (Feature request)
Version:mysql-5.6.23 ndb-7.4.5 OS:Linux (Discovered on Oracle Linux)
Assigned to: CPU Architecture:Any
Tags: ndb_restore

[7 Apr 2015 13:41] Edward Mackenzie
ndb_restore does not seem to catch the SIGHUP signal (not obviously at least).

This was noticed when trying to restore a database backup on a remote system via ssh. All backup files were local to the database cluster, but the ndb_restore command was called remotely.

When the ssh session either timed out or was closed (VPN connection timeout) after backgrounding the ndb_restore process the ndb_restore process just stops - albeit not immediately.

After some extensive searching, I found that this was being caused by SIGHUP. While there are ways around this - I am reporting it as a bug because there is no logging to indicate that this is what has happened.

This can be avoided by executing the ndb_restore command using nohup, or by using disown on an existing process.

How to repeat:
Open an ssh connection to the database cluster.

Start restoring a large database, background the ndb_restore process.

Disconnect the ssh session.

Expected behavior would be for the process to continue running in the background. However, the process just stops with no log message.

Suggested fix:
Either catch and ignore the SIGHUP signal, or catch it, log that it has been caught then stop.

I would recommend that SIGHUP should be ignored.
[8 Apr 2015 11:59] MySQL Verification Team
Hi Eduard,

This is designed behavior so not a bug, but is a feature request worth working on :)

all best
Bogdan Kecman
[27 Apr 2015 4:24] MySQL Verification Team
Workaround: use screen