[Mojolicious] Re: Troubleshooting Hypnotoad Workers
Yeah, I concur that the standard hot swap model probably isn't compatible with a foreground process. Thanks for the input. I know I'm not deploying in the 'typical' configuration, and unfortunately that's not really up to me. However, I'd like to use this opportunity to try to give back somehow - even if that's just putting my questions and experiences here for others who might wind up in the same situation. I could see the possibility of writing an adapter for the service manager that would handle registering the new server's pid with the service manager and perhaps using the SO_REUSEPORT socket option to remain bound to the same port. I could be mistaken, but I don't think that being run as a foreground process == no hotswapping. I think it moves more into the idea of "managed" hotswapping. -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Troubleshooting Hypnotoad Workers
No, sending USR2 (not reloading) to a foreground process does not make any sense. http://mojolicio.us/perldoc/Mojo/Server/Hypnotoad#USR2 On Monday, April 6, 2015 at 5:58:10 PM UTC+2, Nathan Waddell wrote: > > I was hoping to be able to take advantage of hot swapping, but the service > manager does not appear to be able to support this. I may indeed have to > scale back and go with prefork. > > Another configuration I am considering is running Ngix under the service > manager, and having Nginx start hypnotoad. Though I don't know if this > would comply with policy, so I will have to determine that first. > -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Troubleshooting Hypnotoad Workers
I was hoping to be able to take advantage of hot swapping, but the service manager does not appear to be able to support this. I may indeed have to scale back and go with prefork. Another configuration I am considering is running Ngix under the service manager, and having Nginx start hypnotoad. Though I don't know if this would comply with policy, so I will have to determine that first. -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
Re: [Mojolicious] Hypnotoad Feature Request: -v and --version
No. On Monday, April 6, 2015 at 5:13:08 PM UTC+2, Nathan Waddell wrote: > > Thanks, Glen. That's exactly what I'm using at the moment, but would a > patch to Mojolicious::Command::hypnotoad that provides the same > functionality be seen as having value? > > On Friday, April 3, 2015 at 4:43:05 PM UTC-5, tempire wrote: >> >> mojo version >> >> >> On Apr 3, 2015, at 3:42 PM, Nathan Waddell wrote: >> >> I would like to be able to check the version of Hypnotoad at the command >> line with hypnotoad -v or hypnotoad --version. It would be additionally >> nice if the long form (--version) gave more in-depth output regarding the >> build, like the difference between perl -v and perl -V . >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Mojolicious" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to mojolicious...@googlegroups.com. >> To post to this group, send email to mojol...@googlegroups.com. >> Visit this group at http://groups.google.com/group/mojolicious. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Troubleshooting Hypnotoad Workers
Why do you use hypnotoad if running in the foreground? I don't see any benefit over using "prefork": $ perl /path/to/app.pl prefork On Monday, April 6, 2015 at 5:11:26 PM UTC+2, Nathan Waddell wrote: > > Thanks for the advice and input. > > I am running Hypnotoad underneath a UNIX service management application, > and after quite a bit of debugging, I am not able to replicate the problem > when I run Hypnotoad on its own. So perhaps this is more of a fault with > the service manager. Hypnotoad is running in foreground mode, launched by > the service manager. I'm sure this is not a typical configuration, but I > have to work with what I have. Hotswappability has already proven an issue > with the Service Manager, as during hot swap it wants to keep track of the > original hypnotoad server and is unaware of the new server's pid. > > I am considering writing a simple wrapper script that will launch > hypnotoad - something similar to Clustericious::Command::hypnotoad. > > Are there any different deployment strategies that anyone can recommend > for running hypnotoad / Mojo::Server::Prefork as a foreground process? > > On Saturday, April 4, 2015 at 4:17:46 AM UTC-5, sri wrote: >> >> How can I troubleshoot this further to determine: >>> >>>1. Why does Hypnotoad think it still needs to kill non-existent >>>processes? >>>2. Why isn't it starting new ones? >>> >>> >> Never seen this before, but i'll gladly track it down if you can provide >> an example application that would allow me to replicate the problem. >> Otherwise i'm afraid you'll have to track this down yourself, somewhere in >> Mojo::Server::Prefork. >> >> https://github.com/kraih/mojo/blob/master/lib/Mojo/Server/Prefork.pm >> >> -- >> sebastian >> > -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
Re: [Mojolicious] Hypnotoad Feature Request: -v and --version
Thanks, Glen. That's exactly what I'm using at the moment, but would a patch to Mojolicious::Command::hypnotoad that provides the same functionality be seen as having value? On Friday, April 3, 2015 at 4:43:05 PM UTC-5, tempire wrote: > > mojo version > > > On Apr 3, 2015, at 3:42 PM, Nathan Waddell > wrote: > > I would like to be able to check the version of Hypnotoad at the command > line with hypnotoad -v or hypnotoad --version. It would be additionally > nice if the long form (--version) gave more in-depth output regarding the > build, like the difference between perl -v and perl -V . > > -- > You received this message because you are subscribed to the Google Groups > "Mojolicious" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mojolicious...@googlegroups.com . > To post to this group, send email to mojol...@googlegroups.com > . > Visit this group at http://groups.google.com/group/mojolicious. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Troubleshooting Hypnotoad Workers
Thanks for the advice and input. I am running Hypnotoad underneath a UNIX service management application, and after quite a bit of debugging, I am not able to replicate the problem when I run Hypnotoad on its own. So perhaps this is more of a fault with the service manager. Hypnotoad is running in foreground mode, launched by the service manager. I'm sure this is not a typical configuration, but I have to work with what I have. Hotswappability has already proven an issue with the Service Manager, as during hot swap it wants to keep track of the original hypnotoad server and is unaware of the new server's pid. I am considering writing a simple wrapper script that will launch hypnotoad - something similar to Clustericious::Command::hypnotoad. Are there any different deployment strategies that anyone can recommend for running hypnotoad / Mojo::Server::Prefork as a foreground process? On Saturday, April 4, 2015 at 4:17:46 AM UTC-5, sri wrote: > > How can I troubleshoot this further to determine: >> >>1. Why does Hypnotoad think it still needs to kill non-existent >>processes? >>2. Why isn't it starting new ones? >> >> > Never seen this before, but i'll gladly track it down if you can provide > an example application that would allow me to replicate the problem. > Otherwise i'm afraid you'll have to track this down yourself, somewhere in > Mojo::Server::Prefork. > > https://github.com/kraih/mojo/blob/master/lib/Mojo/Server/Prefork.pm > > -- > sebastian > -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Why does Mojo::Server::Daemon debugging print to STDERR?
That is simply not true. STDERR is not just for "errors", despite the name. It is also for diagnostic messages, and pretty much anything that should not be considered the "regular ouput" from the application. I will never vote in favor of allowing any such DEBUG messages (enabled by an environment variable) to be sent to a log file. You could however do it manually by redirecting STDERR (2) to a log file. When that is said: This should never ever be done in production. Doing so adds an overhead that slows down your application. The STDERR constants used through Mojolicous (and other CPAN modules) are simply for developers to get that extra bit of information about what is going on under the hood when nothing else makes sense. I also have no idea why you want this. You ask for something, without explaining what it solves. On Monday, April 6, 2015 at 4:54:21 PM UTC+2, Nathan Waddell wrote: > > Would there be value seen in a patch that allowed a log path to be used as > the value of MOJO_DAEMON_DEBUG? > > MOJO_DAEMON_DEBUG='/var/log/mojo.debug' > > On Monday, April 6, 2015 at 9:49:37 AM UTC-5, Nathan Waddell wrote: >> >> Looking at the source, I do indeed see that it uses warn. >> >> I am deploying hypnotoad as a foreground process being run and monitored >> under a service manager. This service manager is designed along UNIX >> conventions, one of which is that STDERR should be reserved for true >> errors. >> >> I think I could create a warn handler, but I imagine there would still be >> difficulty separating true warns from simple debugging. Is there a >> technique I could employ to work around this? >> > -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Why does Mojo::Server::Daemon debugging print to STDERR?
> > It would get rejected. > In fact, this thread makes me wonder if all *_DEBUG environment variables should be removed or made completely private. -- sebastian -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Why does Mojo::Server::Daemon debugging print to STDERR?
> > Would there be value seen in a patch that allowed a log path to be used as > the value of MOJO_DAEMON_DEBUG? > It would get rejected. -- sebastian -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Why does Mojo::Server::Daemon debugging print to STDERR?
Would there be value seen in a patch that allowed a log path to be used as the value of MOJO_DAEMON_DEBUG? MOJO_DAEMON_DEBUG='/var/log/mojo.debug' On Monday, April 6, 2015 at 9:49:37 AM UTC-5, Nathan Waddell wrote: > > Looking at the source, I do indeed see that it uses warn. > > I am deploying hypnotoad as a foreground process being run and monitored > under a service manager. This service manager is designed along UNIX > conventions, one of which is that STDERR should be reserved for true > errors. > > I think I could create a warn handler, but I imagine there would still be > difficulty separating true warns from simple debugging. Is there a > technique I could employ to work around this? > -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Why does Mojo::Server::Daemon debugging print to STDERR?
> > I am deploying hypnotoad as a foreground process being run and monitored > under a service manager. This service manager is designed along UNIX > conventions, one of which is that STDERR should be reserved for true errors. > Just to be absolutely clear, unlike the application logger, those debug messages are not a supported feature. They are meant for core developers, and will not be made any more friendly than absolutely necessary. -- sebastian -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
[Mojolicious] Re: Why does Mojo::Server::Daemon debugging print to STDERR?
Looking at the source, I do indeed see that it uses warn. I am deploying hypnotoad as a foreground process being run and monitored under a service manager. This service manager is designed along UNIX conventions, one of which is that STDERR should be reserved for true errors. I think I could create a warn handler, but I imagine there would still be difficulty separating true warns from simple debugging. Is there a technique I could employ to work around this? -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at http://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.