Skip to content
This repository has been archived by the owner. It is now read-only.

Add command-line argument to run pywebsocket daemonized #85

Closed
GoogleCodeExporter opened this issue Aug 20, 2015 · 10 comments
Closed

Add command-line argument to run pywebsocket daemonized #85

GoogleCodeExporter opened this issue Aug 20, 2015 · 10 comments

Comments

@GoogleCodeExporter
Copy link

@GoogleCodeExporter GoogleCodeExporter commented Aug 20, 2015

We use pywebsocket at Mozilla as part of our automated test infrastructure.  
When we run tests under gdb, pywebsocket captures ctrl+c's meant for the 
debugger and kills itself.

I have a simple patch which adds a command-line flag to ignore SIGINTs.  Would 
you be willing to take it?

Original issue reported on code.google.com by justin.l...@gmail.com on 9 Dec 2010 at 4:52

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Aug 20, 2015

Original comment by justin.l...@gmail.com on 9 Dec 2010 at 5:03

Attachments:

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Aug 20, 2015

Sorry, not navigating this bug tracker too well.  Above is a patch.  :)

Original comment by justin.l...@gmail.com on 9 Dec 2010 at 5:03

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Aug 20, 2015

And here's the corresponding Mozilla bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=613813

Original comment by justin.l...@gmail.com on 9 Dec 2010 at 5:04

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Aug 20, 2015

I understand what you need. But this sounds specific to your test suite 
architecture. For now, could you try having some stub python code that masks 
SIGINT on your side? Will this work for you?

e.g.

pywebsocket_ignore_sigint.py
====
import signal

from mod_pywebsocket.standalone import _main

if __name__ == '__main__':
  signal.signal(signal.SIGINT, signal.SIG_IGN)
  _main()
====

Original comment by tyoshino@chromium.org on 10 Dec 2010 at 6:41

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Aug 20, 2015

If I understand your problem correctly, it might solve the problem to have a 
functionality to launch a stand-alone server as a daemon process.

I think daemonization would be a valid feature request, and we probably should 
implement it.
(I think daemonization will only work on Unix (and will not on Windows), but I 
hope this limitation won't block your use cases)

Original comment by yutak@chromium.org on 10 Dec 2010 at 7:33

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Aug 20, 2015

> If I understand your problem correctly, it might solve the problem to have a 
> functionality to launch a stand-alone server as a daemon process.

Could you elaborate on this?  If it only works on *nix, that's fine with me.  :)

Original comment by justin.l...@gmail.com on 15 Dec 2010 at 12:14

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Aug 20, 2015

daemon() is basically a combination of fork and setsid. A daemon process is 
separated from its parent and belongs to a new process group, thus signals to 
the parent process will no longer reach the child (daemon) process.

I hope this clarifies your question.

Original comment by yutak@chromium.org on 15 Dec 2010 at 2:32

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Aug 20, 2015

Oh, I see.  Yes, I think daemon() would solve the problem.  In the meantime, 
we'll probably just use a wrapper script.

Original comment by justin.l...@gmail.com on 15 Dec 2010 at 9:16

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Aug 20, 2015

Original comment by tyoshino@chromium.org on 17 Dec 2010 at 4:47

  • Changed title: Add command-line argument to run pywebsocket daemonized
  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

@ricea
Copy link
Contributor

@ricea ricea commented Jun 4, 2020

Closing WontFix as no further changes will be made to this version of pywebsocket.

@ricea ricea closed this as completed Jun 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants