DD on Linux hangs for no reason on expression runner bot.

ID:2293888
 
Sep 14 2017, 3:28 pm
BYOND Version:511
Operating System:Linux
Web Browser:Firefox 55.0
Applies to:Dream Daemon
Status: Open
Issue hasn't been assigned a status value.
Descriptive Problem Summary:
I have a Discord bot that allows me to run snippets of DM code and get the results back easily. Recently I noticed that it became incredibly slow, taking 20+ seconds to run, whereas usually it was almost instant.

The bot works by grabbing the code, wrapping it in some other code so it instantly runs then exits. The code that gets produced looks like this:

var/a/b=new
/a/New()
    world.log << "derp"
var/c/d=new
/c/New()
    shutdown()


So DD just runs it immediately, exits (20 seconds later apparently) and my bot reads the output back to Discord.

Running the code snippets with DD manually and the code instantly executes, then DD proceeds to hang doing nothing, not even consuming any CPU, for 20+ seconds.

While attempting to figure out id:2293882 I ran DD with strace and I noticed it was throwing a TON of SIGALRMs while it's doing nothing, so that's probably related.

$ strace -feprocess byond/bin/DreamDaemon code.dmb
execve("byond/bin/DreamDaemon", ["byond/bin/DreamDaemon", "code.dmb"], [/* 28 vars */]) = 0
strace: [ Process PID=32215 runs in 32 bit mode. ]
Thu Sep 14 23:06:35 2017
Auto-safety mode: ultrasafe (no file access)
World opened on network port 35594.
Welcome BYOND! (5.0 Public Version 511.1385)
derp
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_USER, si_pid=32215, si_uid=1001} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
exit_group(0)                           = ?
+++ exited with 0 +++
Sep 14 2017, 10:39 pm
The alarm signal is just the timer.

I'm not sure why the shutdown is being delayed. It's possible that maybe the world is trying to determine hub reachability and is waiting for the hub to call it back.
Sep 28 2017, 1:37 am
I've seen similar on my own machine, exactly 20 seconds of delay before shutdown.

BYOND version does not seem to affect it, but the user I run as does: if I run it as my IRC bot's user, my Hello World test program takes 1.006±0.001 seconds to execute; if I run it as my own user, it takes 21.006±0.001 seconds.

nyx@thanatos ~/tmp
$ cat time.dme
/world/New()
        world.log << "foo"
        del(src)
nyx@thanatos ~/tmp
$ strace -feprocess DreamDaemon time.dmb
execve("/home/nyx/byond/use/bin/DreamDaemon", ["DreamDaemon", "time.dmb"], [/* 41 vars */]) = 0
strace: [ Process PID=6882 runs in 32 bit mode. ]
Thu Sep 28 07:36:03 2017
Auto-safety mode: ultrasafe (no file access)
World opened on network port 33307.
Welcome BYOND! (5.0 Beta Version 511.1366)
foo
--- SIGALRM {si_signo=SIGALRM, si_code=SI_USER, si_pid=6882, si_uid=1000} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
exit_group(0)                           = ?
+++ exited with 0 +++



bot32@thanatos:/home/nyx/tmp$ strace -feprocess DreamDaemon time.dmb
execve("/home/nyx/byond/use/bin/DreamDaemon", ["DreamDaemon", "time.dmb"], [/* 22 vars */]) = 0
strace: [ Process PID=19710 runs in 32 bit mode. ]
Thu Sep 28 07:37:17 2017
Auto-safety mode: ultrasafe (no file access)
World opened on network port 49621.
Welcome BYOND! (5.0 Beta Version 511.1366)
foo
--- SIGALRM {si_signo=SIGALRM, si_code=SI_USER, si_pid=19710, si_uid=1002} ---
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
exit_group(0)                           = ?
+++ exited with 0 +++
Dec 23 2017, 3:33 pm
Ok so, some more info here. I enabled network sandboxing on the DD process using net none (giving the DD process only 1 network interface, a unique lo) in a Firejail profile, and it starts hanging. Without it works fine (it's been really inconsistent whether it hung before)
Jun 19 2018, 1:07 pm
I have figured out a workaround for this.

Alright.

Get ready for it.

eval("")


Calling this before the shutdown() call causes DD to not delay on shutdown.

Literally. What.
Jun 20 2018, 12:48 am
I work around this issue in my bot by causing BYOND to segfault using some slightly less than good DM when I want to terminate execution """cleanly"""