3👍
It looks like you don’t care what the result of the system call is, so I would assume you are trying to do some sort of offline(or background) processing.
I would suggest a cleaner way of going about it rather than directly executing a program. Use a queueing system such as Gearman to queue up processing tasks and then have a separate worker that consumes items from the queue.
This has the advantage of protecting your server when large traffic spikes happen, so you don’t fork off a process each time a request to that view is made. You can consume items as slow or as fast as you decide, independent of traffic.
Traffic may not be an issue, but I personally think it is a cleaner design decision as well.
2👍
I encountered the same problem running Django with nginx+uwsgi. Often the breaking point is the module of web-server, in my case it was uwsgi. Adding <close-on-exec/>
solved this problem. From other side the fastcgi module doesn’t cause to view to hung on background processes.
I don’t know which server do you use, so you can check this behavior with various modules (uwsgi, mod_wsgi, fastcgi) and see what is more suitable for you.
And try to execute in background:
subprocess.Popen(["/bin/sleep", "10", "&"])
- [Django]-Error on django runserver – OverflowError: getsockaddrarg: port must be 0-65535
- [Django]-Django: DeleteView + HttpResponseNotAllowed
- [Django]-Translation in celery tasks
- [Django]-Problem rendering a Django form field with different representation
- [Django]-Django Graphene writing mutations with multiple layers of nested foreign keys
- [Django]-Django rest registration