**** BEGIN LOGGING AT Fri Sep 13 02:59:57 2019 Sep 13 03:15:24 Python's nature is to "make things simple" by requiring a complicated environment. the reason Python 2 lasted so long is because of dependencies on ancient libraries. It's sort of Linux's DLL hell, only with python instead. Anyhow I need sleep. Simulation is taking a long time. Sep 13 03:24:25 Okay. Sep 13 03:24:28 no issue. Sep 13 03:24:41 Later for now! Sep 13 05:47:30 permission denied on my macbook terminal Sep 13 13:40:11 description as dll hell is all too accurate. I don't think I've ever succesfully installed anything reasonably complicated that's made of python. There's always something incompatible, and a horror of multiple installation methods, none of which work Sep 13 13:40:28 for someone used to apt-get, it's a disaster. Sep 13 13:42:08 maybe the easy and convenient virtual environment has caused reduced pressure on library devs to get rid of their ancient deps Sep 13 13:47:01 perhaps. I note that there's a big effort to move to python3 at last. But often, my problem is that I'm trying to use long-forgottten code pcked off the web that was written in an no-longer-maintained environment. nobody's going to be updating those to python3 so they'll just become even more unmaintainable Sep 13 13:47:56 well, unmaintaned projects that no longer work isn't exactly exclusive to python Sep 13 13:48:49 and there's always a trade-off between maintaining backwards compatibility for the sake of ancient unmaintained code versus being able to clean shit up and not be forever burdened with the mistakes of the past Sep 13 13:54:40 yeah, it's partly becauise I'm not experienced enough with python to recognise what needs doing. I'd be a lot less bothered by having to make some old C work Sep 13 13:55:26 I know there are automated tools for python2->python3 code conversion, though I don't know how well those work Sep 13 14:00:07 there was a thread on The Register recently about the python3 campaign. It seemed to conclude that the stock 2 to 3 converter was to be avoided. Sep 13 14:01:16 how so? obviously the changed made by such tools should be manually confirmed, but I'd assume it's at least a decent start Sep 13 14:01:31 one notable comment was that it output 3-only code but the writer claimed it was fairly easy to produce portable code manually Sep 13 14:01:49 you can use modernize to get code that works on both 2 and 3 Sep 13 14:01:59 although I don't see the point in maintaining python2-compatibility :P Sep 13 14:02:21 (j/k, for module authors there obviously is) Sep 13 14:03:00 http://python-future.org/automatic_conversion.html Sep 13 14:03:28 the porting guide (https://docs.python.org/3/howto/pyporting.html) links to that Sep 13 14:10:53 the division operator and strings vs bytes will probably still require manual inspection... the former because whether to use / or // will depend on the type of values (python2 / acts like python3 / if one or both operands is float, or like python3 // if both operands are int (or python2 long)), which can't be determined statically Sep 13 14:11:07 and strings vs bytes may require API revision as well Sep 13 14:55:01 m Sep 13 20:08:37 Do not worry about my question about .service files, Gunicorn, and Flask/Python apps. I got it, yea boy! Sep 13 20:08:44 systemd! Sep 13 20:14:15 you didn't ask a question, so I doubt anyone is worrying about it Sep 13 21:15:33 @zmatt: I asked yesterday. Sep 13 21:15:55 Dang it. You are right. Sep 13 21:15:58 Sheesh. Sep 13 21:25:58 I just viewed my entire "message" and it was not in question form. @zmatt: Please stop being correct all the time. Sep 13 21:26:23 Dang it. @zmatt: Will you please stop being correct all the time? Sep 13 21:31:48 Forget it. Sep 13 21:34:29 I feel like I am harassing you already. Peace for now! Sep 13 21:50:14 I don't really see a question with or without question mark Sep 13 21:51:07 oh unless you mean the stackexchange link yesterday Sep 13 21:51:19 (which you directed at a specific person) Sep 13 21:53:25 never mind, that one has been answered already Sep 13 21:55:03 Yep. Sep 13 21:55:11 I answered it myself. Numero Uno! Sep 13 21:55:52 I am about to ask another question on that site about uWSGI and .service files. That PID is for the birds. Sep 13 21:57:39 oh I meant the answer from Simba Sep 13 21:58:18 Oh. Sep 13 21:58:27 He was talking about SuperVisor. Sep 13 21:58:31 your python script doesn't require a shebang (the #!/usr/bin/python3), which is fortunate since it is the wrong shebang in this case (since you're using python from the venv) Sep 13 21:58:48 Oh. Sep 13 21:58:52 he gave an example for supervisor, his answer applied to both supervisor and systemd Sep 13 21:59:04 Oh. Sep 13 21:59:45 Maybe that is why my server w/ uWSGI is not running right now. Sep 13 22:00:04 ? Sep 13 22:00:11 it shouldn't have any effect Sep 13 22:00:15 Oh. Sep 13 22:00:34 My server is showing active on the BBBW but online is another story. Sep 13 22:00:36 like I said, it is superfluous in this case, and python will just treat it as a comment like any other line starting with # Sep 13 22:00:44 Oh. Sep 13 22:00:45 Okay. Sep 13 22:01:22 failing to stop sounds weird Sep 13 22:01:28 (ExecStop is almost never needed btw) Sep 13 22:01:32 Oh. Sep 13 22:01:50 does stopping the service using systemctl just hang, or? Sep 13 22:01:56 W/ gunicorn, the service would not stop until I unplugged my board, BBBW. Sep 13 22:02:23 what does systemctl status show after systemctl stop ? Sep 13 22:02:34 (for your service) Sep 13 22:02:48 For gunicorn? Sep 13 22:03:11 Oh. Nothing. It showed nothing. Sep 13 22:03:20 Oh! Sep 13 22:03:24 for your service yes (which again should probably be run as user service even though you're currently running it as system service) Sep 13 22:03:27 what do you mean "nothing" Sep 13 22:03:29 I know what you are describing to me now. Sep 13 22:03:40 Hold Please. Sep 13 22:03:46 Let me make a backup. Sep 13 22:03:59 I will run it again w/out the ExecStop= portion. Sep 13 22:04:31 also btw your "TheNameOfMyPythonApp" also doesn't need to be executable (the chmod +x) for the same reason it doesn't need a shebang: it's not executed directly like a program, it's loaded as a python module by gunicorn Sep 13 22:04:37 huh? what did you even put there? Sep 13 22:04:48 there shouldn't be any ExecStop Sep 13 22:05:08 I will show you. Sep 13 22:05:10 Please hold. Sep 13 22:05:13 Let me catch up. Sep 13 22:06:52 oh wtf they use one in the example in the gunicorn docs? what is this nonsense Sep 13 22:07:00 https://pastebin.com/p4DaS0s5 is the old file w/out the ExecStop=. Sep 13 22:08:35 that looks fine, although making it a user service might be better (but it looks fine in either case) Sep 13 22:08:49 the ExecStop you have there commented out looks like nonsense? Sep 13 22:09:07 I tried to run the .service file like that. I am receiving errors today. Sep 13 22:09:10 Please hold. Sep 13 22:11:51 Okay. Sep 13 22:12:00 It works. I had to stop some other services on the same port. Sep 13 22:12:14 i.e. even w/out the ExecStop= directive. Sep 13 22:12:22 you can obviously have only one server listening on a given port Sep 13 22:12:29 Right. Sep 13 22:12:40 I had another service running b/c I forgot to stop it. Sep 13 22:13:08 @zmatt: Okay. Sep 13 22:13:24 So, do you want to know still what happens when I try to stop it? Sep 13 22:13:31 W/out ExecStop=? Sep 13 22:13:52 yes, though also try adding KillMode=mixed to the [Service] section Sep 13 22:14:26 Okay. I read that adding ExecStop w/ ExecStart is needed on FreeDesktop.org. Sep 13 22:14:42 read that where? Sep 13 22:14:53 Hold. I will retrieve it. Sep 13 22:15:00 since I see no reason to use it here Sep 13 22:16:36 https://www.freedesktop.org/software/systemd/man/systemd.service.html under ExecStart= at the end before the options. Sep 13 22:17:06 (Services lacking both ExecStart= and ExecStop= are not valid.) Sep 13 22:17:13 ^ Sep 13 22:17:30 Oh. Nevermind. Sep 13 22:17:34 I just got what that meant. Sep 13 22:18:04 oh that's just a poor way to phrase it... they mean it's not valid if both ExecStart and ExecStop are missing, i.e. you need to have at least either ExecStart or ExecStop Sep 13 22:18:14 oh it does say that right before Sep 13 22:18:18 Ha. Sep 13 22:18:30 anyway, you don't need ExecStop Sep 13 22:18:31 Dang it. Okay, okay. So, where were we? Sep 13 22:18:34 Okay. Sep 13 22:18:43 You are right. Sep 13 22:18:46 I just tested it. Sep 13 22:18:58 I wonder what exactly happened yesterday. Who knows? Sep 13 22:18:58 you might need KillMode=mixed to ensure gunicorn can clean up its own child processes Sep 13 22:19:05 Okay. Sep 13 22:20:55 and my guess would be that when it "didn't stop" systemd was still waiting for processes to stop after sending SIGTERM (the timeout is pretty long, more than a minute) Sep 13 22:21:00 but that's just speculation Sep 13 22:21:39 systemctl status YOURSERVICE would show whether that's the case Sep 13 22:21:54 Probably. I actually found a KillSignal=SIGQUIT directive. Sep 13 22:22:02 don't do that Sep 13 22:22:03 Would I use this. Sep 13 22:22:07 Okay. Sep 13 22:22:20 I saw this idea from a uWSGI server. Sep 13 22:22:56 if KillMode=mixed doesn't work, then please provide more info (status and any relevant log) Sep 13 22:23:17 @zmatt: I am already figuring out what happened. The server(s) were not working b/c one was completely on and running while I tried others and tried to stop the other servers. One was always running, i.e. just not the one I thought should run. Sep 13 22:23:18 Okay. Sep 13 22:23:37 that makes sense too, i.e. you just being an idiot :) Sep 13 22:23:44 Right! Sep 13 22:23:53 add KillMode=mixed anyway Sep 13 22:23:58 Okay. Sep 13 22:25:16 (it's probably not essential though) Sep 13 22:25:20 w/ uWSGI, I am receiving an Internal Server Error message. Sep 13 22:25:22 Okay. Sep 13 22:25:31 that sounds like it's running successfully Sep 13 22:25:37 Right. Sep 13 22:25:49 W/ status, it shows running. Sep 13 22:26:01 why are you using gunicode or uwsgi anyway? Sep 13 22:26:27 weren't you just using flask directly previously? it may not be suited for "production" environments, but just for your own little tests it should be fine Sep 13 22:26:45 and it's simpler Sep 13 22:26:52 B/c...I do not want to try to get in trouble for running Flask apps in a production env. Sep 13 22:26:53 Right. Sep 13 22:27:01 you don't *have* a production env Sep 13 22:27:06 Now yet! Sep 13 22:27:23 What if I use something in production? Sep 13 22:27:24 so worry about that when you do, not during development Sep 13 22:27:29 Oh. Sep 13 22:27:30 Okay. Sep 13 22:27:48 It is telling me that there is no python app found. Sep 13 22:27:54 That is my issue. Sep 13 22:27:58 "it" ? Sep 13 22:27:58 Sheesh. Sep 13 22:28:10 systemctl status ...service. Sep 13 22:29:07 I figured it out. Sep 13 22:29:23 uWSGI and the file are in separate dir. Sep 13 22:29:41 again, full details please, especially since you're prone to be talking about multiple random topics at the same time (i.e. gunicorn, uwsgi, running flask directly). provide service file, _full_ output of 'systemctl status YOURSERVICE', and recent log output ('journalctl -u YOURSERVICE -n 100' gives the last 100 log lines) Sep 13 22:29:58 Oh. Sep 13 22:30:01 Please hold. Sep 13 22:30:15 unless you already figured it out of course, in which case it doesn't matter anymore Sep 13 22:30:34 1959 /home/debian/virt/env/bin/uwsgi --http 0.0.0.0:5000 --wsgi-file MotoCapeIII.py --master --processes 4 --threads 2 Sep 13 22:30:53 --wsgi-file MotoCapeIII.py should be --module MotoCapeIII:app. Sep 13 22:31:30 why are you simultaneously messing with gunicorn and uwsgi? Sep 13 22:31:38 I am testing both. Sep 13 22:31:45 you need neither Sep 13 22:31:56 I want to learn more. Sep 13 22:32:00 More! Sep 13 22:32:22 Programming is fun too but file adminitration is just as fun. Sep 13 22:32:34 add a s in there somewhere. Sep 13 22:35:16 https://pastebin.com/1EpGxfZF is giving an internal server error and is active. Sep 13 22:37:22 I see why now. Sep 13 22:37:30 Something about the uid/gid. Sep 13 22:37:35 and root. Sep 13 22:38:40 btw using multiple threads and that many processes is probably a bad idea on a beaglebone... I'd use a single thread and one or maybe two processes Sep 13 22:38:54 Okay. Got it. Sep 13 22:38:55 or maybe two threads and 1 process Sep 13 22:38:58 but two in total Sep 13 22:39:28 also, you're still running your services as root, which is a bad idea Sep 13 22:39:50 either use a user service (still recommended) or add a User=debian directive to the [Service] section Sep 13 22:40:02 I cannot use systemctl w/out the sudo. Sep 13 22:40:03 Okay. Sep 13 22:40:48 All I am doing is providing sudo systemctl start my.service instead of systemctl start my.service. Sep 13 22:41:02 ohh wait, I remember something, can you tell me the output of: sudo grep UsePAM /etc/ssh/sshd_config Sep 13 22:41:19 sudo is required for starting/stopping system services yes Sep 13 22:41:26 Okay. Sep 13 22:41:54 UsePAM yes Sep 13 22:41:56 user services use 'systemctl --user' (without sudo) Sep 13 22:41:58 ok Sep 13 22:42:05 Aw! Sep 13 22:42:07 Okay. Sep 13 22:42:34 I misinterpreted what you were saying, I thought you meant you couldn't use systemctl --user to control user services but I guess that's not what you meant Sep 13 22:42:47 the correct commands are of course in the comments in my example user service file Sep 13 22:42:55 Okay. Sep 13 22:43:42 Also. Sep 13 22:43:49 as for your internal server error, unfortunately none of what's in your pastebin gives any indication of what's wrong, so it's probably an uwsgi configuration problem Sep 13 22:44:02 I could not write to service files in /etc/systemd/system w/out sudo. Sep 13 22:44:11 Okay. Sep 13 22:44:16 of course Sep 13 22:44:19 Okay. Sep 13 22:44:21 sudo is required to mess with system services Sep 13 22:44:27 not for user services though, again a reason to use those Sep 13 22:44:28 I just wanted to make sure. Sep 13 22:44:35 Okay. Got it. Sep 13 22:48:06 I figured it out. Sep 13 22:48:23 Sheesh. It was about --module instead of --wsgi-file. Sep 13 22:54:48 @zmatt: It is still taking a "year" to cancel the .service but that is okay. Sep 13 22:54:55 I have a power button! Sep 13 22:54:56 no it's not Sep 13 22:55:02 again, status please Sep 13 22:55:03 Oh. Sep 13 22:55:16 and log Sep 13 22:55:37 four processes and two threads. I forgot. Sep 13 22:55:38 and are you still talking about gunicorn or now about uwsgi? Sep 13 22:55:45 uWSGI. Sep 13 22:55:53 since earlier you were talking about gunicorn when you said it didn't stop Sep 13 22:55:56 I need to change that... Sep 13 22:56:06 or at least it seemed like you were Sep 13 22:56:10 I was discussing uWSGI when it would not stop. Gunicorn works as expected. Sep 13 22:56:15 oh Sep 13 22:56:37 I was jumping from subject to subject. Sep 13 22:56:41 Sorry. Sep 13 23:00:33 that's due to uwsgi misbehaving by default, it needs to "die-on-term" option enabled in its configuration Sep 13 23:00:58 Oh. Okay. I will read about that idea. Sep 13 23:01:24 although the docs say this is not needed anymore, but if so then it's not clear when they fixed it Sep 13 23:02:01 I think the uWSGI instance was installed via pip3. So, I have no way of controlling the executable. Sep 13 23:02:55 I guess there are other areas where it is found. I will find that info. later. Sep 13 23:03:05 areas = files Sep 13 23:04:49 I have no idea what you mean Sep 13 23:04:57 anyway, passing --die-on-term as commandline option might fix it Sep 13 23:05:52 Okay. Sep 13 23:05:58 I will try that too. Sep 13 23:06:10 @zmatt: Are you bored w/ me yet? Sep 13 23:08:59 Yes, yes. You are. I knew it. Sep 13 23:09:00 Boy! Sep 13 23:09:34 why are you using uwsgi anyway? especially when using it standalone (without a webserver) it is even worse (from a security perspective) than using flask standalone Sep 13 23:09:58 Oh. Sep 13 23:10:12 B/c...I always wanted to show off something I accomplished. Sep 13 23:10:28 If I show off something I have done, I might need a production server. Sep 13 23:10:56 oh never mind uwsgi does have integrated http server functionality too Sep 13 23:11:09 @zmatt: I will learn about the Apache2 or Nginx config. stuff later. Sep 13 23:11:11 if you use --http, which you do iirc Sep 13 23:12:44 you don't need a production server "to show off something" you've done. Sep 13 23:12:50 Are you sure? Sep 13 23:13:09 You remember correctly. --http was used. Sep 13 23:14:29 @zmatt: I have been reading on how to promote my server w/ a real server like Nginx. Sep 13 23:14:34 running flask standalone is fine for most purposes, just don't enable debug mode if you're not on a trusted network Sep 13 23:14:44 Oh. Sep 13 23:14:49 since it allows execution of arbitrary commands via the network Sep 13 23:14:57 That is probably what happened to me at the Maker Faire. Sep 13 23:14:58 Okay. Sep 13 23:15:25 debug mode is enabled using the FLASK_ENV=development or FLASK_DEBUG=1 environment vars Sep 13 23:15:50 Okay. Sep 13 23:15:56 I need to write that down. Sep 13 23:16:14 as long as you omit there, it should run in production config Sep 13 23:16:20 usually, I type in debug=True in my file. Sep 13 23:17:03 or that Sep 13 23:17:04 So, it would be something like: app.run(host="", port=, debug=True). Sep 13 23:17:11 that obviously also enables debug mode Sep 13 23:17:15 Oh! Sep 13 23:17:18 which is what you want during development Sep 13 23:17:24 but not if you're on a public network Sep 13 23:17:50 Now, I know. Development and production is different. I get this fact but flask tells their users to use a real server instead. Sep 13 23:17:51 Oh. Sep 13 23:18:03 So, debug=True is not for public networks. Sep 13 23:18:06 Got it. Sep 13 23:18:59 Well. Taking it out when I promote work next time. Sep 13 23:19:12 yeah it might still warn you shouldn't use flask's built-in webserver in production environments, but that's because "it doesn't scale well", i.e. if you're serving lots of users then you may run into performance problems when using flask standalone instead of using an wsgi server... that's not likely to be relevant for you Sep 13 23:19:15 I see one of the local sites is Flask oriented, too. Sep 13 23:19:32 Okay. Sep 13 23:19:34 Got it. Sep 13 23:19:41 nextdoor.com Sep 13 23:20:01 Those people are having people telling on each other all day. Sep 13 23:20:06 I think for you, using uwsgi or some other wsgi server just adds hassle and makes debugging harder Sep 13 23:20:20 Okay but it is fun. Fun! Sep 13 23:20:39 @zmatt: Why do you want me to quit? Sep 13 23:21:03 I know you know better already. Sep 13 23:21:10 I am still having fun and trying to learn more. Sep 13 23:21:17 Who knows? I might do something one day. I never know. Sep 13 23:21:19 ok Sep 13 23:21:30 Thank you. Sep 13 23:22:34 Break time! **** ENDING LOGGING AT Sat Sep 14 02:59:57 2019