routes in windows service not working??

[Dave]

I generally am not the person to be monkeying around with things on Windows.  That said, one of my customers is about to take over management and ownership of a web2py application I have written for them.  I seem to be having an issue testing the deployment for them.

I created an options.py file and the service installs and starts properly.  Unfortunately, for some reason it does not appear the routes.py file is being parsed on startup though.  Even though the default app is set, a request to / still attempts to go to /welcome/...  If I go in to the admin interface and choose reload routes, everything works...  until the service is restarted that is.

If I run web2py from the command line .. ie python web2py.py -p 80 -a 'password', the routes.py file gets parsed on startup.

Any ideas?

[Dana Frost]

I found the answer....

Ruben Orduz Mon, 19 Mar 2012 07:49:41 -0700

You have to re-start the web2py server NOT from the tk GUI (start/stop) server buttons but you have to close that GUI app and re-start web2py.exe.  It worked for me after that. So a full restart will re-parse the top level routes.py routes.  This may be the same on UNIX but I never used the tk GUI for web2py so I did not see this until I used Windows. 

[Stephen Tanner]

I Think I tracked down the issue.

In the windows service, it just imports the HttpServer class from main, and then creates one using the options.py for its settings.

However, when starting a web2py not as a service, it makes a call to main.py

In gluon.main.py we can see that rewrite.load is imported and then later just run with global file scope as a call to load()

This however is not done in association to creating or starting a web-server so when the windows service creates the HttpServer object no call is made to load()

To fix this edit gluon.winservice.py, and add the following lines to the try block in the start function

...
try:
    from rewrite import load
    load()
    self.server.start()    
except:
    ....

This causes it to read the routes.py file before starting the server and should cause the desired action.

[Tim Richardson]

possibly another reason to use nssm on windows

[Stephen Tanner]

Forgive my lack of knowledge and experience with nssm but how would it help in this situation?

On Apr 12, 2013 7:09 AM, "Tim Richardson" <t...@growthpath.com.au> wrote:

possibly another reason to use nssm on windows

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "web2py-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py/oWmanNSKxdc/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Niphlod]

from web2py's standpoint, having someone else (the nssm process) to care for service integration is more straightforward, i.e. it runs exactly as if it was launched "normally".
Of course winservice.py can be patched and fixed etc etc etc but either someone takes care of testing it under every Windows OS, for every web2py release, for every web2py feature, or it will remain as something that "sometimes work, sometimes doesn't".

Given that for each job there's "a best tool", and that the "best tool" for this job is:
-  free
- available
- requires no absolute time to set up

I'd go for nssm all the times (and that's why a slice was posted at http://www.web2pyslices.com/slice/show/1614/nssm-webserver-and-scheduler-as-services-in-windows-oses on the matter)

[Stephen Tanner]

Interesting.

However why call nssm the "best" way to do this but still ship the winservice.py file?

If nssm was truly *the* way to do this then I would think the book (which was just updated) would have removed the section about the winservice.py and only talk about nssm or at least make an effort to promote nssm over the native script.

This doesn't make a whole lot of sense from the standpoint of having "everything" in the box with web2py.

As far as support goes, Massimo is intent on supporting ie 7 for web2py's editor because some people still use it. So supporting new/different versions of windows is already being done not to mention the method for setting up a system service has hardly changed since XP (12+years)

Regardless I already have a 2 line patch that ill submit to fix this issue once the site is back up.

[Niphlod]

However why call nssm the "best" way to do this but still ship the winservice.py file?

Because things gets discussed and possibly overlooked.
There are a few open issues with the way web2py handles services and absolutely no-one willing to take "responsibility" to test it more than the current "once on a while". A full coverage in fact has never been tested (and probably never worked). That being said, sometimes it works without hiccups. The "batteries included" predicament stands as long as your implementation works, all the times.
A very few users are using it (or a very few users just needed once and forgot it), and when this pops up once in a while, a patch is threw in and then the user disappears.
The moment he needs to update web2py and finds that his previous patch didn't really solve the problem, there's another iteration on the matter.
 

If nssm was truly *the* way to do this then I would think the book (which was just updated) would have removed the section about the winservice.py and only talk about nssm or at least make an effort to promote nssm over the native script.

I would have done it and proposed in the past, but I'm not the boss and usually there are a few POVs to consider.
 

This doesn't make a whole lot of sense from the standpoint of having "everything" in the box with web2py.

On the other end, doesn't make real sense to continue supporting something that is clearly not tested and with a very little userbase (but with a lot of people complaining for it the moment they realize they fall into the "sometime doesn't" category).
 

As far as support goes, Massimo is intent on supporting ie 7 for web2py's editor because some people still use it. So supporting new/different versions of windows is already being done not to mention the method for setting up a system service has hardly changed since XP (12+years)

same as before. My POV is more or less "if you have only IE7 as a browser, use notepad"  given that IE7 is currently being replaced in enterprises too (and is very well below the 5% on the "browser's share").
In any case, it's one thing to make a web page compatible with IE6(7,8,9,10) and is another making web2py hooking up into XP,Vista,Seven,8,2003,2008 (32 and 64 bits) service managers, with all the options working ok, with source and binary distributions, for python2.5, 2.6, 2.7 (someone with pypy necessities could come up as well) and have a proof of it (i.e. not saying "this should work" but "this works").

If you want it the way it is, i.e. "sometime works, sometime doesn't", by all means continue to use it and send a patch every time it breaks, but please take into consideration that ditching it and using nssm will save you, angry users and developers a lot of headaches.

[Stephen Tanner]

A lot of valid points however as i stated it is only a 2 line fix.

The reason this fix is needed is because of the

On Apr 12, 2013 8:53 AM, "Niphlod" <nip...@gmail.com> wrote:

However why call nssm the "best" way to do this but still ship the winservice.py file?

Because things gets discussed and possibly overlooked.
There are a few open issues with the way web2py handles services and absolutely no-one willing to take "responsibility" to test it more than the current "once on a while". A full coverage in fact has never been tested (and probably never worked). That being said, sometimes it works without hiccups. The "batteries included" predicament stands as long as your implementation works, all the times.
A very few users are using it (or a very few users just needed once and forgot it), and when this pops up once in a while, a patch is threw in and then the user disappears.
The moment he needs to update web2py and finds that his previous patch didn't really solve the problem, there's another iteration on the matter.

"A few open issues?" WindowsXP scripts still work on VIsta/7/8 because it is nothing more than a simple registry entry.

As far as maintaining the code, did you look at the two lines I proposed to add?

from rewrite import load

load()

What is to maintain? the load() function in rewrite is the same one that gluon.main.py uses.

If you would like to propose a better place to call the load() function in gluon.main.py such that it is always galled before launching an HttpServer then that would actually be useful and then we would not need to call load separately in the winservice.py file.

 

If nssm was truly *the* way to do this then I would think the book (which was just updated) would have removed the section about the winservice.py and only talk about nssm or at least make an effort to promote nssm over the native script.

I would have done it and proposed in the past, but I'm not the boss and usually there are a few POVs to consider.
 

 

The other issue with this is the fact that it is *another* thing to install rather than just being included. Makes it a lot harder to get web2py approved by corporate IT/Sys-addmins if you have to install a whole bunch of separate apps and each app has to be vetted. 

This doesn't make a whole lot of sense from the standpoint of having "everything" in the box with web2py.

On the other end, doesn't make real sense to continue supporting something that is clearly not tested and with a very little userbase (but with a lot of people complaining for it the moment they realize they fall into the "sometime doesn't" category).
 

Clearly you are already supporting it by shipping a winservice.py file and someone just forgot to call the load() function to read the routes.py file. I don't understand what you are so against?
 

As far as support goes, Massimo is intent on supporting ie 7 for web2py's editor because some people still use it. So supporting new/different versions of windows is already being done not to mention the method for setting up a system service has hardly changed since XP (12+years)

same as before. My POV is more or less "if you have only IE7 as a browser, use notepad"  given that IE7 is currently being replaced in enterprises too (and is very well below the 5% on the "browser's share").
In any case, it's one thing to make a web page compatible with IE6(7,8,9,10) and is another making web2py hooking up into XP,Vista,Seven,8,2003,2008 (32 and 64 bits) service managers, with all the options working ok, with source and binary distributions, for python2.5, 2.6, 2.7 (someone with pypy necessities could come up as well) and have a proof of it (i.e. not saying "this should work" but "this works").

If you want it the way it is, i.e. "sometime works, sometime doesn't", by all means continue to use it and send a patch every time it breaks, but please take into consideration that ditching it and using nssm will save you, angry users and developers a lot of headaches.

--
 

Again, all the version of windows that are currently supported XP,  Vista, 7, and 8 it makes no difference how you register a service. Even when 64 bit.

Do yourself a favour and take a look at gluon.main.py and notice how out of place the call to load() is.

That file is a bit of a hodgepodge, a global variable, a bunch of global functions, a class definition and a call to load(). It is clear that to make web2py more modular that the call to load() should not just be thrown in there. That being said, I do not have enough experience with the code base to propose a better place within the main.py file other than possibly just before the call to server.start in the start method of the HttpClass. I however am not certain this would always be called even when using different web-servers (e.g. calling anyserver.py and using rocket, cherrypy, gunicorn, tornado, etc.)

This caused me to go a safer route and add this call to the winservice.py file instead. Are you saying this is wrong/bad/dumb? So far I can't tell what exactly it is you are against only that you are against fixing the issue.

Please contribute something helpful so we can get the best solution possible available to the users, developers, and admins of web2py. Keeping in mind that part of web2pys goal is to lower the barrier of entry into developing rich applications. This is partially accomplished by including just about everything one needs in the web2py package and making it easy to deploy into production. Adding another external software requirement needlessly only raises the bar and prevents that many more people from discovering how awesome this framework can be.

[Massimo Di Pierro]

Thanks! In trunk.

[Massimo Di Pierro]

I agree that perhaps we should remove winservice. I would like to hear more opinions on the matter form windows users. removing winservice requires adding some steps (namely downloading and using nssm).

[Niphlod]

you're overreaching. Of course your 2 line fix will be accepted: my point was more or less "if I were you (handing over the management to my customer)" I'd go for the safer route of nssm.
If you search in the group you'll see a few issues reported already and almost one other is still open in the bugtracker.

That being said, "me" is not supporting winservice. "me" just sees a lot of potential problems continuing to ship it with web2py.

There's a strong possibility that nssm is yet in your sysadmin toolbelt (and if not, he'll like it.)

All the rest of the post is FUD.