many dancer apps with Starman (part 3)
In part 1 [http://www.backup-manager.org/pipermail/dancer-users/2011-July/001614.html] I dipped my toes into powering many apps on the same computer using Starman. I had a few errors, and the solutions, that I documented. I also received a very helpful reply from Pedro Melo [http://www.backup-manager.org/pipermail/dancer-users/2011-July/001617.html] suggesting that instead of one script for all the apps, I should fire up separate Starman processes for each app. In part 2 [http://www.backup-manager.org/pipermail/dancer-users/2011-July/001616.html] I described a more generic scenario that would cover most of the circumstances I could dream of at the moment at my work. In part 3, [http://www.backup-manager.org/pipermail/dancer-users/2011-July/001633.html], I described that I was getting a cryptic error from Plack::Builder complaining that there was an "Error while loading foo.psgi: Paths need to start with / at /Users/punkish/perl5/perlbrew/perls/perl-5.14.1/lib/site_perl/5.14.1/Plack/Builder.pm line 89." Now, taking Perdo Melo's advice, I am just launching separate Starman processes directly calling the `dancer -a` generated /path/to/webapp/bin/app.pl with $plackup -E production -D -s Starman --workers=10 -p 5000 -a path/to/webapp/bin/app.pl I change the port number for each app to match the apache proxy settings. So, here I ask the following: the above is working, but is rapidly going to become cumbersome in three regards -- 1. It will become tricky keeping track of the port numbers for each app, and make sure they match between what has been set in httpd.conf (for proxy purposes) and what has been used to call in the `plackup` command; 2. It will become very cumbersome shutting off or restarting one or more Starman app because I would have to find out the parent process of each app, and kill that in order to kill all the child workers; and 3. If I have 10 or 20 apps on the same server, with 10 Starman workers for each app, I would have 100 or 200 perl processes running on my computer even if my apps are really low traffic. I tried setting the number of workers to 2 or 2, but found that the server started dropping connections. Is having so many perl processes running not problematic?
Hi, On Sun, Jul 10, 2011 at 8:41 PM, Mr. Puneet Kishor <punk.kish@gmail.com> wrote: [...]
So, here I ask the following: the above is working, but is rapidly going to become cumbersome in three regards --
1. It will become tricky keeping track of the port numbers for each app, and make sure they match between what has been set in httpd.conf (for proxy purposes) and what has been used to call in the `plackup` command;
It does. I run about 10 small apps this way, documentation is the only solution I've got. You could play tricks with $0 to add the port number and the name of the app so that you can easily check with ps but I never felt the need for that.
2. It will become very cumbersome shutting off or restarting one or more Starman app because I would have to find out the parent process of each app, and kill that in order to kill all the child workers; and
Two solutions: the first is the quicker to implement, the second is the variation on the first that I use. First: Use the --pid option of plackup and give it a very descriptive name, in a well known directory. With that, you can use kill -SIGNAL_NAME `head -1 /path/to/pids/app_descriptive_name` ... You can even use tab completion. Second: create yet another dancer app :) that lists the pid files directory, and allows you to remote kill the apps. Basically a Dancer-powered web frontend to the previous solution. There are extra stuff that you can do if you reallly have lots of apps, like having an extra config file per app and a script that takes care of starting plackup with all the proper parameters based on that config file. You could even generate the apache/nginx reverse proxy config from the same file, to make sure the port always matches. I did that for a client...
3. If I have 10 or 20 apps on the same server, with 10 Starman workers for each app, I would have 100 or 200 perl processes running on my computer even if my apps are really low traffic. I tried setting the number of workers to 2 or 2, but found that the server started dropping connections. Is having so many perl processes running not problematic?
Depends on the memory available and the load each app will have. You could start less workers (2 or 3) per app, monitor their usage and increase those who need that (make these values parameters on you config file, for example). I believe starman preloads the app so most of the memory will be shared between workers. Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ http://about.me/melo xmpp:melo@simplicidade.org mailto:melo@simplicidade.org
On Jul 11, 2011, at 6:59 AM, Pedro Melo <melo@simplicidade.org> wrote:
Hi,
On Sun, Jul 10, 2011 at 8:41 PM, Mr. Puneet Kishor <punk.kish@gmail.com> wrote: [...]
So, here I ask the following: the above is working, but is rapidly going to become cumbersome in three regards --
1. It will become tricky keeping track of the port numbers for each app, and make sure they match between what has been set in httpd.conf (for proxy purposes) and what has been used to call in the `plackup` command;
It does. I run about 10 small apps this way, documentation is the only solution I've got.
You could play tricks with $0 to add the port number and the name of the app so that you can easily check with ps but I never felt the need for that.
2. It will become very cumbersome shutting off or restarting one or more Starman app because I would have to find out the parent process of each app, and kill that in order to kill all the child workers; and
Two solutions: the first is the quicker to implement, the second is the variation on the first that I use.
First: Use the --pid option of plackup and give it a very descriptive name, in a well known directory. With that, you can use kill -SIGNAL_NAME `head -1 /path/to/pids/app_descriptive_name` ... You can even use tab completion.
Second: create yet another dancer app :) that lists the pid files directory, and allows you to remote kill the apps. Basically a Dancer-powered web frontend to the previous solution.
Wow! This is a seriously kludgey situation, your suggestions seem like the best way to alleviate this mess somewhat. I guess, in a way, Apache has the same kind of mess, but it must be all under the hood. For me, as a user, I like that I have a single command (apachectl) with which I can start, stop or restart the server.
3. If I have 10 or 20 apps on the same server, with 10 Starman workers for each app, I would have 100 or 200 perl processes running on my computer even if my apps are really low traffic. I tried setting the number of workers to 2 or 2, but found that the server started dropping connections. Is having so many perl processes running not problematic?
Depends on the memory available and the load each app will have. You could start less workers (2 or 3) per app, monitor their usage and increase those who need that (make these values parameters on you config file, for example).
Well, it was not the memory usage that was/is a problem right now. At this time I have only a few Dancer apps, but they are going to grow to about 10 or a dozen or so. Right now, the problem I experienced was that when I started Starman with only two workers, it would simply drop every other connection. If I kept on hitting the refresh button on the browser, every other connection would croak. Increasing the number of workers fixed this. This tells me that perhaps the minimum realistic number of workers might be between 5 and 10, even for low traffic web sites. Which means that with 10 or so apps, I will have 50 to a 100 Perl processes running concurrently on my computer.
I believe starman preloads the app so most of the memory will be shared between workers.
I could be wrong, but the way I understand Apache to work is that it will start a few workers, and then fork a new child for every incoming connection. So, even with 10 apps, it would not have more than a dozen or so child processes. In any case, no matter how many there are, they can be easily controlled by a single apachectl invocation. I am liking Starman for now, and it is kinda like mod_perl in its persistence, but I am also discovering a new-found appreciation for Apache.
2. It will become very cumbersome shutting off or restarting one or more Starman app because I would have to find out the parent process of each app, and kill that in order to kill all the child workers; and
another solution: use something like runit[1]. You create a configuration for each "service" (your applications) with runit. When you want to restart this application you can ask runit to restart this service, and you don't have to think about the process. This is the solution I use, I can post more details if needed. [1] http://smarden.org/runit/ -- franck cuny http://lumberjaph.net - http://github.com/franckcuny
On Tue, Jul 12, 2011 at 11:19 AM, franck <franck@lumberjaph.net> wrote:
2. It will become very cumbersome shutting off or restarting one or more Starman app because I would have to find out the parent process of each app, and kill that in order to kill all the child workers; and
another solution: use something like runit[1]. You create a configuration for each "service" (your applications) with runit. When you want to restart this application you can ask runit to restart this service, and you don't have to think about the process. This is the solution I use, I can post more details if needed.
There is also Ubic: https://github.com/berekuk/Ubic
I've used Daemontools in past with good results: http://www.deepakg.com/prog/2011/01/deploying-a-perl-dancer-application-on-a... On Tue, Jul 12, 2011 at 10:26 AM, sawyer x <xsawyerx@gmail.com> wrote:
On Tue, Jul 12, 2011 at 11:19 AM, franck <franck@lumberjaph.net> wrote:
2. It will become very cumbersome shutting off or restarting one or more Starman app because I would have to find out the parent process of each app, and kill that in order to kill all the child workers; and
another solution: use something like runit[1]. You create a configuration for each "service" (your applications) with runit. When you want to restart this application you can ask runit to restart this service, and you don't have to think about the process. This is the solution I use, I can post more details if needed.
There is also Ubic: https://github.com/berekuk/Ubic
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Hi, On Tue, Jul 12, 2011 at 9:44 AM, Deepak Gulati <deepak.gulati@gmail.com> wrote:
I've used Daemontools in past with good results: http://www.deepakg.com/prog/2011/01/deploying-a-perl-dancer-application-on-a...
I use daemontools for everything but with Starman, you loose the option of graceful restarts. The way starman does graceful restarts requires a master process PID change, and that makes it incompatible with daemontools. Thats actually why I'm working on a super-deamon for PSGI apps, with gracefull restarts and preloading but without master process pid changes so it is daemontools-compatible. Compatibility with starman and twiggy is also a requirement. Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ http://about.me/melo xmpp:melo@simplicidade.org mailto:melo@simplicidade.org
On Jul 12, 2011, at 4:14 AM, Pedro Melo wrote:
The way starman does graceful restarts requires a master process PID change
Could you please tell me how to do a graceful restart with Starman? I am also looking at the other suggestions as well (runit, daemontools, the init script submitted by Stefan, etc.), but I need something Mac OS X friendly. Right now, if I do user@computer ~$ps -ax | grep 'starman master' 17612 ?? 0:00.74 starman master 17619 ?? 0:00.78 starman master 17626 ?? 0:00.60 starman master 19852 ttys002 0:00.00 grep starman master I have no idea which process is controlling which app, and, in any case, I have to do a bunch of `kill` commands. There must be some better way. Thanks, Puneet.
On 07/12/2011 10:26 AM, sawyer x wrote:
On Tue, Jul 12, 2011 at 11:19 AM, franck<franck@lumberjaph.net> wrote:
2. It will become very cumbersome shutting off or restarting one or more Starman app because I would have to find out the parent process of each app, and kill that in order to kill all the child workers; and
another solution: use something like runit[1]. You create a configuration for each "service" (your applications) with runit. When you want to restart this application you can ask runit to restart this service, and you don't have to think about the process. This is the solution I use, I can post more details if needed.
There is also Ubic: https://github.com/berekuk/Ubic
And I wrote a init script for starting Dancer applications with plackup/starman. It is attached. Regards Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team
On Jul 11, 2011, at 6:59 AM, Pedro Melo wrote:
First: Use the --pid option of plackup and give it a very descriptive name, in a well known directory. With that, you can use kill -SIGNAL_NAME `head -1 /path/to/pids/app_descriptive_name` ... You can even use tab completion.
Second: create yet another dancer app :) that lists the pid files directory, and allows you to remote kill the apps. Basically a Dancer-powered web frontend to the previous solution.
The above is a really sweet (sounding) solution. A web front end to admin Dancer apps would be fantastic. Heh... maybe I will scratch the itch. What is the way to restart an already running app? Am I the only one who is a bit lost with the documentation for Starman and other servers (or, even the plackup documentation)? Puneet.
Hi, On Thu, Jul 14, 2011 at 10:57 PM, Mr. Puneet Kishor <punk.kish@gmail.com> wrote:
On Jul 11, 2011, at 6:59 AM, Pedro Melo wrote:
First: Use the --pid option of plackup and give it a very descriptive name, in a well known directory. With that, you can use kill -SIGNAL_NAME `head -1 /path/to/pids/app_descriptive_name` ... You can even use tab completion. [...] What is the way to restart an already running app? Am I the only one who is a bit lost with the documentation for Starman and other servers (or, even the plackup documentation)?
Err :)... Starman perldoc, under DESCRIPTION, the Signals item starts with: "Supports HUP for graceful restarts..."... Use the --pid option to write the master process pid number to a file so you don't have to use ps (which on Mac OS X lacks the -f option unfortunately). Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ http://about.me/melo xmpp:melo@simplicidade.org mailto:melo@simplicidade.org
me continuing to be dense below -- On Jul 15, 2011, at 3:05 AM, Pedro Melo wrote:
Hi,
On Thu, Jul 14, 2011 at 10:57 PM, Mr. Puneet Kishor <punk.kish@gmail.com> wrote:
On Jul 11, 2011, at 6:59 AM, Pedro Melo wrote:
First: Use the --pid option of plackup and give it a very descriptive name, in a well known directory. With that, you can use kill -SIGNAL_NAME `head -1 /path/to/pids/app_descriptive_name` ... You can even use tab completion. [...] What is the way to restart an already running app? Am I the only one who is a bit lost with the documentation for Starman and other servers (or, even the plackup documentation)?
Err :)... Starman perldoc, under DESCRIPTION, the Signals item starts with: "Supports HUP for graceful restarts..."...
Yes, I read that, but I don't know what that means (I know more Unix than my neighbor, but that is still waaaaay too little). I know that Ctrl-C sends a HUP, and so does `kill`, doesn't it?
Use the --pid option to write the master process pid number to a file so you don't have to use ps (which on Mac OS X lacks the -f option unfortunately).
Yes, I am able to use your suggested technique $ kill `head -1 /path/to/pidfile/with/descriptive/name` What SIGNAL can I send for a restart? Puneet.
On 15/07/11 11:15 PM, Mr. Puneet Kishor wrote
Err :)... Starman perldoc, under DESCRIPTION, the Signals item starts with: "Supports HUP for graceful restarts..."...
Yes, I read that, but I don't know what that means (I know more Unix than my neighbor, but that is still waaaaay too little). I know that Ctrl-C sends a HUP, and so does `kill`, doesn't it? Without specifying a signal to kill it defaults to TERM. man kill will show you all the signals and their names. Yes, I am able to use your suggested technique
$ kill `head -1 /path/to/pidfile/with/descriptive/name`
What SIGNAL can I send for a restart?
kill -HUP pid will send a HANGUP (restart) Matt
Hi, On Fri, Jul 15, 2011 at 2:15 PM, Mr. Puneet Kishor <punk.kish@gmail.com> wrote:
On Jul 15, 2011, at 3:05 AM, Pedro Melo wrote:
On Thu, Jul 14, 2011 at 10:57 PM, Mr. Puneet Kishor <punk.kish@gmail.com> wrote:
On Jul 11, 2011, at 6:59 AM, Pedro Melo wrote:
First: Use the --pid option of plackup and give it a very descriptive name, in a well known directory. With that, you can use kill -SIGNAL_NAME `head -1 /path/to/pids/app_descriptive_name` ... You can even use tab completion. [...] What is the way to restart an already running app? Am I the only one who is a bit lost with the documentation for Starman and other servers (or, even the plackup documentation)?
Err :)... Starman perldoc, under DESCRIPTION, the Signals item starts with: "Supports HUP for graceful restarts..."...
Yes, I read that, but I don't know what that means (I know more Unix than my neighbor, but that is still waaaaay too little). I know that Ctrl-C sends a HUP, and so does `kill`, doesn't it?
Ok, assume that you've started your app like this: starman --pid my_x_app.pid bin/app.pl This will start a starman with the default number of workers and it will write the PID of the manager process into the my_x_app.pid file. To restart the app do: kill -HUP `head -1 my_x_app.pid` The head -1 my_x_app.pid will get the first line of the file, the PID of the process and the kill command will send the SIGHUP signal to that pid. This will restart your app, gracefully, without loosing requests. To try, do this: * open three new windows; * on window 1, start you app under starman: starman --pid my_x_app.pid bin/app.pl * on window 2, type the command kill -HUP `head -1 my_x_app.pid` but don't execute it yet * on window 3, type ab -c 4 -n 4000 http://127.0.0.1:5000/ * start the command on window 3 (this will generate 4000 requests with 4 concurrent clients); * while that is running, go to windows 2 and execute the command. You can execute it multiple times (!! is your friend, just type !!<ENTER>). Each time, the app will restart. * when the ab command on window 3 finishes, notice that you didn't have any errors. You did have longer response times for some requests, while the app is restarting, but no lost requests. Its possible to remove even the longer response times using server-starter *I think* but I don't use it, don't know how well it works.
Use the --pid option to write the master process pid number to a file so you don't have to use ps (which on Mac OS X lacks the -f option unfortunately).
Yes, I am able to use your suggested technique
$ kill `head -1 /path/to/pidfile/with/descriptive/name`
What SIGNAL can I send for a restart?
-HUP, see above Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ http://about.me/melo xmpp:melo@simplicidade.org mailto:melo@simplicidade.org
HI again, On Fri, Jul 15, 2011 at 2:51 PM, Pedro Melo <melo@simplicidade.org> wrote:
Its possible to remove even the longer response times using server-starter *I think* but I don't use it, don't know how well it works.
I got curious, and its actually quite simple to use start_server. To start your app: start_server --port=8811 --pid-file=my_x_app.pid --status-file=my_x_app.status -- starman bin/app.pl You need both --pid-file and --status-file. To restart: start_server --pid-file=my_x_app.pid --status-file=my_x_app.status --restart The command will wait to see if the restart was successful, by monitoring the status file. Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ http://about.me/melo xmpp:melo@simplicidade.org mailto:melo@simplicidade.org
On Jul 15, 2011, at 9:02 AM, Pedro Melo wrote:
HI again,
On Fri, Jul 15, 2011 at 2:51 PM, Pedro Melo <melo@simplicidade.org> wrote:
Its possible to remove even the longer response times using server-starter *I think* but I don't use it, don't know how well it works.
I got curious, and its actually quite simple to use start_server.
To start your app:
start_server --port=8811 --pid-file=my_x_app.pid --status-file=my_x_app.status -- starman bin/app.pl
You need both --pid-file and --status-file.
To restart:
start_server --pid-file=my_x_app.pid --status-file=my_x_app.status --restart
The command will wait to see if the restart was successful, by monitoring the status file.
The above is great help. However, I am trying to use `start_server` with `plackup` options and getting the following error $start_server --port=5000 --pid-file=pids/app.pid --status-file=status/app.status -- plackup -s Starman -w 10 -E production -D -a ~/Sites/blog/bin/app.pl start_server (pid:4453) starting now... starting new worker 4454 new worker 4454 seems to have failed to start, exit status:0 starting new worker 4461 new worker 4461 seems to have failed to start, exit status:0 starting new worker 4468 new worker 4468 seems to have failed to start, exit status:0 starting new worker 4475 ^Cworker 4475 died unexpectedly with status:0, restarting starting new worker 4482 received INT, sending TERM to all workers:4482 worker 4482 died, status:0 exitting and, in spite of the above, it seemed to have started several starman master processes. That is not what I wanted. $ps -ax | grep 'starman master' 4455 ?? 0:00.01 starman master 4462 ?? 0:00.01 starman master 4469 ?? 0:00.01 starman master 4476 ?? 0:00.01 starman master 4483 ?? 0:00.01 starman master 4496 ttys001 0:00.00 grep starman master of course, the bare plackup command works fine $plackup -s Starman -w 10 -E production -D -a ~/Sites/blog/bin/app.pl The above starts only one master and 10 workers. Suggestions?
On Monday 18 July 2011 22:43:25 Mr. Puneet Kishor wrote:
The above is great help. However, I am trying to use `start_server` with `plackup` options and getting the following error
$start_server --port=5000 --pid-file=pids/app.pid --status-file=status/app.status -- plackup -s Starman -w 10 -E production -D -a ~/Sites/blog/bin/app.pl start_server (pid:4453) starting now... starting new worker 4454 new worker 4454 seems to have failed to start, exit status:0 starting new worker 4461 new worker 4461 seems to have failed to start, exit status:0 starting new worker 4468 new worker 4468 seems to have failed to start, exit status:0 starting new worker 4475 ^Cworker 4475 died unexpectedly with status:0, restarting starting new worker 4482 received INT, sending TERM to all workers:4482 worker 4482 died, status:0 exitting
and, in spite of the above, it seemed to have started several starman master processes. That is not what I wanted.
$ps -ax | grep 'starman master' 4455 ?? 0:00.01 starman master 4462 ?? 0:00.01 starman master 4469 ?? 0:00.01 starman master 4476 ?? 0:00.01 starman master 4483 ?? 0:00.01 starman master 4496 ttys001 0:00.00 grep starman master
of course, the bare plackup command works fine
$plackup -s Starman -w 10 -E production -D -a ~/Sites/blog/bin/app.pl
The above starts only one master and 10 workers.
Suggestions?
I suspect that start_server is expecting what it runs to stay around, whereas plackup forks a new process then exits - and every time it does, start_server tries to start another. -- David Precious ("bigpresh") http://www.preshweb.co.uk/ "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
On Jul 18, 2011, at 4:56 PM, David Precious wrote:
On Monday 18 July 2011 22:43:25 Mr. Puneet Kishor wrote:
The above is great help. However, I am trying to use `start_server` with `plackup` options and getting the following error
$start_server --port=5000 --pid-file=pids/app.pid --status-file=status/app.status -- plackup -s Starman -w 10 -E production -D -a ~/Sites/blog/bin/app.pl start_server (pid:4453) starting now... starting new worker 4454 new worker 4454 seems to have failed to start, exit status:0 starting new worker 4461 new worker 4461 seems to have failed to start, exit status:0 starting new worker 4468 new worker 4468 seems to have failed to start, exit status:0 starting new worker 4475 ^Cworker 4475 died unexpectedly with status:0, restarting starting new worker 4482 received INT, sending TERM to all workers:4482 worker 4482 died, status:0 exitting
and, in spite of the above, it seemed to have started several starman master processes. That is not what I wanted.
$ps -ax | grep 'starman master' 4455 ?? 0:00.01 starman master 4462 ?? 0:00.01 starman master 4469 ?? 0:00.01 starman master 4476 ?? 0:00.01 starman master 4483 ?? 0:00.01 starman master 4496 ttys001 0:00.00 grep starman master
of course, the bare plackup command works fine
$plackup -s Starman -w 10 -E production -D -a ~/Sites/blog/bin/app.pl
The above starts only one master and 10 workers.
Suggestions?
I suspect that start_server is expecting what it runs to stay around, whereas plackup forks a new process then exits - and every time it does, start_server tries to start another.
Does that mean I can't use start_server as above? I am curious -- how are others solving this problem. I seem to be one of the lonely Dancer users who has still not gotten the hang of starting several apps and managing them. While not directly a Dancer issue, surely this is a problem that Dancer servers would face, no? Puneet.
On Mon, Jul 18, 2011 at 10:59 PM, Mr. Puneet Kishor <punk.kish@gmail.com> wrote:
On Jul 18, 2011, at 4:56 PM, David Precious wrote:
On Monday 18 July 2011 22:43:25 Mr. Puneet Kishor wrote:
The above is great help. However, I am trying to use `start_server` with `plackup` options and getting the following error
$start_server --port=5000 --pid-file=pids/app.pid --status-file=status/app.status -- plackup -s Starman -w 10 -E production -D -a ~/Sites/blog/bin/app.pl start_server (pid:4453) starting now... starting new worker 4454 new worker 4454 seems to have failed to start, exit status:0 starting new worker 4461 new worker 4461 seems to have failed to start, exit status:0 starting new worker 4468 new worker 4468 seems to have failed to start, exit status:0 starting new worker 4475 ^Cworker 4475 died unexpectedly with status:0, restarting starting new worker 4482 received INT, sending TERM to all workers:4482 worker 4482 died, status:0 exitting
and, in spite of the above, it seemed to have started several starman master processes. That is not what I wanted.
$ps -ax | grep 'starman master' 4455 ?? 0:00.01 starman master 4462 ?? 0:00.01 starman master 4469 ?? 0:00.01 starman master 4476 ?? 0:00.01 starman master 4483 ?? 0:00.01 starman master 4496 ttys001 0:00.00 grep starman master
of course, the bare plackup command works fine
$plackup -s Starman -w 10 -E production -D -a ~/Sites/blog/bin/app.pl
The above starts only one master and 10 workers.
Suggestions?
I suspect that start_server is expecting what it runs to stay around, whereas plackup forks a new process then exits - and every time it does, start_server tries to start another.
Does that mean I can't use start_server as above?
David is right. You are using -D in the plackup invocation, and that enables "daemon-mode" where plackup forks and goes to background. start_server is compatible with daemon-mode. Just remove the -D from your command and it should work just fine.
I am curious -- how are others solving this problem. I seem to be one of the lonely Dancer users who has still not gotten the hang of starting several apps and managing them. While not directly a Dancer issue, surely this is a problem that Dancer servers would face, no?
I use straight plackup with Twiggy or Starman, it depends on my needs. I don't use -D, and on the production environment, I run my apps inside daemontools supervise. This setup lacks graceful restarts, that's something that I'm working on right now. Well, as soon as I end my fight with 3DSecure WSDL API that is... Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ http://about.me/melo xmpp:melo@simplicidade.org mailto:melo@simplicidade.org
participants (8)
-
David Precious -
Deepak Gulati -
franck -
Matthew Vickers -
Mr. Puneet Kishor -
Pedro Melo -
sawyer x -
Stefan Hornburg (Racke)