Welcome to TDBSoverflow, Our class's own StackOverflow. Our rules:
  1. Use only meaningful and self-explanatory titles
  2. Tag your questions with meaningful keywords
  3. Use upvotes and downvotes to rate the answers
  4. When you receive a satisfying answer - Click the "V" button
Remember: you may get up to 5 bonus points to your final grade!

the application run only for few hours after deattached

+2 votes

העלינו את האתר שלנו לאוויר בעזרת הפקודה הנדרשת לפלאסק : nohup pyhton main.py &

לאחר שיצאנו מהtomcat אכן היה אפשר להכנס ללא בעיה לאתר - כלומר התהליך עבד,

אבל לאחר כ4-3 שעות פתאום לא היה אפשר יותר להכנס אליו ונראה כי החיבור לשרת אבד.

האם יש לך סיבה הגיונית?  יש משהו שאנחנו מפספסים בתהליך?


asked Jan 17, 2018 by assafgoldner (370 points)
So did you eventually figure out what the problem was? Do you mind sharing how you got it to work, I am curious! :P
I hope that it is working now - best of luck!

2 Answers

+1 vote

Suspecting that there's a firewall which truncates the bound socket.

Are you using external imports which require internet access in your HTML/JS files? such as:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script>

Some of the imports open and establish new connections which remain in stale open state, and some firewalls, if exist, may terminate the main socket which initiated the connection.

If you have external dependencies, try to download the offline package instead, and include it in your project (to avoid downloading it every time the page loads).

So that the above import tag becomes:

<script src="example/jquery-3.2.1.min.js"></script>

answered Jan 18, 2018 by karimmahamed (5,190 points)
Also fair to mention that the above makes your views load much faster! :)
+2 votes

There are many different possibilities for the failure of your server, and instead of randomly speculating - the best way to find out the root cause would be taking a look at your server's error logs.

You can take a look at the error handling section in flask documentation to further understand how to peek into the error logs of your server. By default, the server will write the error logs to stderr, as you can see in the logging section.

Best luck!

answered Jan 18, 2018 by babygirl55 (10,420 points)
עשינו את האפשרות הראשונה שkarimmahamed ( הציע אבל האתר עדיין קורס...
עשינו גם את האפשרות השנייה ואלה הלוגים שיצאו(לא משהו חריג):
INFO:werkzeug: - - [18/Jan/2018 20:01:46] "GET / HTTP/1.1" 200 -
INFO:werkzeug: - - [18/Jan/2018 20:01:46] "GET /static/icon.png HTTP/1.1" 200 -
INFO:werkzeug: - - [18/Jan/2018 20:01:48] "GET /Locations HTTP/1.1" 200 -
INFO:werkzeug: - - [18/Jan/2018 20:01:48] "GET /static/Locations_style.css HTTP/1.1" 200 -
INFO:werkzeug: - - [18/Jan/2018 20:01:48] "GET /static/locations_js.js HTTP/1.1" 200 -
INFO:werkzeug: - - [18/Jan/2018 20:01:48] "GET /static/location_background.png HTTP/1.1" 200 -
INFO:werkzeug: - - [18/Jan/2018 20:28:27] "GET /static/powered-by-songkick-white.png HTTP/1.1" 200 -
INFO:werkzeug: - - [18/Jan/2018 20:28:28] "GET /static/bootstrap.min.js HTTP/1.1" 200 -
INFO:werkzeug: - - [18/Jan/2018 20:45:47] "GET /Locations HTTP/1.1" 200 -
INFO:werkzeug: - - [18/Jan/2018 20:45:47] "GET /static/icon.png HTTP/1.1" 200 -
INFO:werkzeug: - - [18/Jan/2018 20:45:50] "GET / HTTP/1.1" 200 -
ואחרי הלוג האחרון שרשום זה פשוט נפסק...
יש עוד רעיונות?
אנחנו אובדי עצות :(
Can't really tell if there's something wrong by only observing the logs here. Did you try running your server on a different free port? Maybe a previous instance of your server is still running on the same port that you are trying to connect to again? Or maybe someone else caught the same port as you?
I took a look at the running instances on the server and found those two lines:
tcp     1195      0     CLOSE_WAIT
tcp     1195      0     CLOSE_WAIT

Saw the same IP's like the ones in the logs that you sent so I assume you picked port 40100 to run your server on. You may have multiple instances still running due to the CLOSE_WAIT flag, which means that your server is waiting for acknowledgement from the client side in order to close.
You should kill all the previous instances running on the port you picked and try deploying again.

More about it:
when running your python server with nohup, try redirecting the standard output errors to a file instead of stdout/stderr. Run it like this:

nohup python server.py &>logs &  

Then after your server crashes again, try to take a look at the log file created in the same folder.