behavior of Minetest after 3 SIGTERMs in a row

[Walker]

I noticed that if minetest hangs because a mod isn't responding or a command like "/emergeblocks" was issued, minetest won't respond to a SIGTERM either.

Of course you can kill minetest with SIGKILL, but that's not good.

However, I noticed that if you send minetest a SIGTERM three times, it will also terminate, no matter how badly it hangs.

What exactly happens in the background?
Does minetest simply kill itself?
Does it cancel all mod executions?
Does it write changes to the map.sqlite so that it is "properly unmounted" or can it be damaged, like with SIGKILL?

Does something happen after the second SIGTERM?

[Walker]

i found in "porting.cpp" two functions:

Code: Select all

static void signal_handler(int sig)
{
	if (!g_killed) {
		if (sig == SIGINT) {
			dstream << "INFO: signal_handler(): "
				<< "Ctrl-C pressed, shutting down." << std::endl;
		} else if (sig == SIGTERM) {
			dstream << "INFO: signal_handler(): "
				<< "got SIGTERM, shutting down." << std::endl;
		}

		// Comment out for less clutter when testing scripts
		/*dstream << "INFO: sigint_handler(): "
				<< "Printing debug stacks" << std::endl;
		debug_stacks_print();*/

		g_killed = true;
	} else {
		(void)signal(sig, SIG_DFL);
	}
}

void signal_handler_init(void)
{
	(void)signal(SIGINT, signal_handler);
	(void)signal(SIGTERM, signal_handler);
}

but non of them are counting.

signal_handler() just set g_killed every time a SIGTERM is received

but why is minetest then closing itself after the third SIGTERM forcefully ?

[Desour]

The first ctrl+C (SIGINT) causes `g_killed=true`, the 2nd sets the singal handler to default (SIG_DFL), the 3rd terminates the process (default action).

Idk if this is intentional. Only having to press 2 times would make more sense to me.

[Walker]

The first ctrl+C (SIGINT) causes `g_killed=true`, the 2nd sets the singal handler to default (SIG_DFL), the 3rd terminates the process (default action).

Idk if this is intentional. Only having to press 2 times would make more sense to me.

ahh... I completely overlooked the SIG_DFL thing... now it makes a bit more sense

here are the three runs, as far as i understand:

1. g_killed is not true, so g_killed is set (right befor the "else")
2. g_killed is set, so signal is redirected to SIG_DFL (after the "else")
3. SIG_DFL is now activated, where SIGTERM has the same effect as SIGKILL

is that right?

that would mean that after receiving SIGTERM three times, minetest is really "killed" in an improper way... that's really stupid.

[Desour]

here are the three runs, as far as i understand:

1. g_killed is not true, so g_killed is set (right befor the "else")
2. g_killed is set, so signal is redirected to SIG_DFL (after the "else")
3. SIG_DFL is now activated, where SIGTERM has the same effect as SIGKILL

is that right?

Yep.

(But at 2. the signal is not redirected. The signal handler is just (un)set.)

[Nininik]

I know this is kinda stupid and may not relate, but what if it is possible to spawn like a crashing entity with a script to manually crash/shutdown server if the SIGTERM/KILL dosent work?

[Walker]

my approach would be different:
don't just set g_killed to true, but count it up
and then perform different actions depending on the value.
for:
1: normal shutdown (with the message that minetest is shutting down because of SIGTERM)
2: do nothing but warn that another SIGTERM will cause a "harder shutdown"
3: simply shut down the LUA VM and then unmount all SQLite files. (no damage should occur)
4: again, do nothing. but this time: warn that another SIGTERM will cause a "even harder shutdown"
5: kill all hanging LUA VMs and other threads and then unmount the SQLite files forcefully
6: display a message that minetest is hanging and that you should kill it with SIGKILL
7: set g_killed to 5 so that the next SIGTERM shows the message again (see 6)