Cdtjkyj

We recently moved our development infrastructure from our own old machines running Ubuntu 12.04 to Google Cloud instances running Ubuntu 18.04.

Developers usually start some screens and run django servers within those screens.

For example, one may create a screen screen -S webserver_5552 and run its django development application within the screen python manage.py runserver 0.0.0.0:5552

On our previous machines, we could detach the screen (ctrl+a d) and come back later (screen -r xxxx.webserver_5552): the django server process would still be here, up and running, and owned by the bash process of the screen.

On the Google Cloud machine, this is, however, working differently and has been driving us crazy. We can still detach the screen, but if we come back later after a while, the django process is no longer owned by the bash process! Instead, it is owned by the init process (ppid set to 1 from ps).

Usually, we got a backtrace from the django process before it received some signals and got his ownership changed, but that's all we got and we can't figure out what's the root cause and how to prevent it:

Traceback (most recent call last):

  File "manage.py", line 65, in <module>

    execute_from_command_line(sys.argv)

  File "/home/testing/env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 367, in execute_from_command_line

    utility.execute()

  File "/home/testing/env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 359, in execute

    self.fetch_command(subcommand).run_from_argv(self.argv)

  File "/home/testing/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 294, in run_from_argv

    self.execute(*args, **cmd_options)

  File "/home/testing/env/local/lib/python2.7/site-packages/django/core/management/commands/runserver.py", line 58, in execute

    super(Command, self).execute(*args, **options)

  File "/home/testing/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 345, in execute

    output = self.handle(*args, **options)

  File "/home/testing/env/local/lib/python2.7/site-packages/django/core/management/commands/runserver.py", line 97, in handle

    self.run(**options)

  File "/home/testing/env/local/lib/python2.7/site-packages/django/core/management/commands/runserver.py", line 106, in run

    autoreload.main(self.inner_run, None, options)

  File "/home/testing/env/local/lib/python2.7/site-packages/django/utils/autoreload.py", line 333, in main

    reloader(wrapped_main_func, args, kwargs)

  File "/home/testing/env/local/lib/python2.7/site-packages/django/utils/autoreload.py", line 304, in python_reloader

    exit_code = restart_with_reloader()

  File "/home/testing/env/local/lib/python2.7/site-packages/django/utils/autoreload.py", line 290, in restart_with_reloader

    exit_code = os.spawnve(os.P_WAIT, sys.executable, args, new_environ)

  File "/home/testing/odesk_android/../env/lib/python2.7/os.py", line 575, in spawnve

    return _spawnvef(mode, file, args, env, execve)

  File "/home/testing/odesk_android/../env/lib/python2.7/os.py", line 548, in _spawnvef

    wpid, sts = waitpid(pid, 0)

OSError: [Errno 4] Interrupted system call

This has been a particularly annoying behavior and we could not figure out the root cause (does it come from ubuntu, GCP, some misconfiguration, ...?).