From info at botpublishing.com Tue Jan 5 13:37:10 2021 From: info at botpublishing.com (Bot-Publishing Inc.) Date: Tue, 5 Jan 2021 08:37:10 -0500 Subject: fresh install configuration problem Message-ID: Hello, I installed the latest Unit package for RHEL 8. When I try to configure a simple demo app, I am getting: 2021/01/05 13:27:07 [info] 13694#13694 "demo" application started 2021/01/05 13:27:07 [alert] 13694#13694 Python failed to import module "temp" ModuleNotFoundError: No module named 'temp' 2021/01/05 13:27:07 [notice] 13630#13630 process 13694 exited with code 1 2021/01/05 13:27:07 [warn] 13633#13633 failed to start application "demo" 2021/01/05 13:27:07 [alert] 13633#13633 failed to apply new conf The JSON config is as following ============================================ { "listeners": { "*:8080": { "pass": "applications/demo" } }, "applications": { "demo": { "type": "python", "path": "/home/ec2-user/bp_tts/tmp/", "module": "temp", "protocol": "wsgi" } } } temp.py ============================================ def application(environ, start_response): start_response("200 OK", [("Content-Type", "text/plain")]) return (b"Hello, Python on Unit!") PWD of temp.py ============================================ /home/ec2-user/bp_tts/tmp Would appreciate any advice. Thank you, gen -------------- next part -------------- An HTML attachment was scrubbed... URL: From tarkhil at over.ru Tue Jan 5 16:19:39 2021 From: tarkhil at over.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCf0L7QstC+0LvQvtGG0LrQuNC5?=) Date: Tue, 5 Jan 2021 19:19:39 +0300 Subject: sane way of cleaning up stale unix sockets? In-Reply-To: <6289051.4vTCxPXJkl@vbart-laptop> References: <4aa7a86a-09cb-cb8a-b6dc-16d53bba4f41@over.ru> <2005944.KlZ2vcFHjT@vbart-laptop> <0fcfdacf-4606-ec9a-6c86-8f3c4804070b@over.ru> <6289051.4vTCxPXJkl@vbart-laptop> Message-ID: Hello Why nxt_listen_socket_create is not used to create sockets other than control? Any positive reason or "still no time to rewrite?" -- Alex On 22.12.2020 17:40, Valentin V. Bartenev wrote: > Actually we thought about a connection test with the algorithm of atomic > creation of such sockets, that was implemented earlier this year for the > control socket: https://hg.nginx.org/unit/rev/0a8840921fd0 > > -- > Valentin > > > > On Tuesday, 22 December 2020 17:14:15 MSK ????????? ?????????? wrote: >> Maybe just https://gavv.github.io/articles/unix-socket-reuse/ ? >> >> On 22.12.2020 17:12, Valentin V. Bartenev wrote: >>> On Saturday, 19 December 2020 18:48:02 MSK ????????? ?????????? wrote: >>>> Hello >>>> >>>> Sometimes unitd leaves behind orphaned unix sockets (well, just >>>> configure it to use some and kill -9!) >>>> >>>> On next start, unitd fails to start because of existing sockets. >>>> >>>> Is there a sane way to clean up them on start? keeping separate list of >>>> sockets-to-remove is a clear way to insainty. >>> [..] >>> >>> Hello, >>> >>> Indeed, this is a problem. That's the reason why the usage of unix sockets >>> in listeners is still undocumented. >>> >>> It's not so easy to fix, because we need to avoid the situation when the socket >>> is used by some other processes and avoid any possible race conditions >>> here. >>> >>> Actually, until it will be fixed I have no better idea than put them all in the >>> same dedicated directory and just clean up everything in it each restart. >>> >>> wbr, Valentin V. Bartenev >>> >>> >>> >>> _______________________________________________ >>> unit mailing list >>> unit at nginx.org >>> https://mailman.nginx.org/mailman/listinfo/unit >> _______________________________________________ >> unit mailing list >> unit at nginx.org >> https://mailman.nginx.org/mailman/listinfo/unit >> > > > > _______________________________________________ > unit mailing list > unit at nginx.org > https://mailman.nginx.org/mailman/listinfo/unit From max.romanov at nginx.com Tue Jan 5 19:47:22 2021 From: max.romanov at nginx.com (Max Romanov) Date: Tue, 5 Jan 2021 22:47:22 +0300 Subject: fresh install configuration problem In-Reply-To: References: Message-ID: Hello, Most likely it?s a permission issue. Try to specify "user": "ec2-user" for your "demo" app in configuration. By default, application starts as "nobody" user and have no permissions to access files in other users? directories. ? Regards, Max > On 5 Jan 2021, at 16:37, Bot-Publishing Inc. wrote: > > Hello, > > I installed the latest Unit package for RHEL 8. > > When I try to configure a simple demo app, I am getting: > > 2021/01/05 13:27:07 [info] 13694#13694 "demo" application started > 2021/01/05 13:27:07 [alert] 13694#13694 Python failed to import module "temp" ModuleNotFoundError: No module named 'temp' > 2021/01/05 13:27:07 [notice] 13630#13630 process 13694 exited with code 1 > 2021/01/05 13:27:07 [warn] 13633#13633 failed to start application "demo" > 2021/01/05 13:27:07 [alert] 13633#13633 failed to apply new conf > > The JSON config is as following > ============================================ > { > "listeners": { > "*:8080": { > "pass": "applications/demo" > } > }, > "applications": { > "demo": { > "type": "python", > "path": "/home/ec2-user/bp_tts/tmp/", > "module": "temp", > "protocol": "wsgi" > } > } > } > > temp.py > ============================================ > def application(environ, start_response): > start_response("200 OK", [("Content-Type", "text/plain")]) > return (b"Hello, Python on Unit!") > > > PWD of temp.py > ============================================ > /home/ec2-user/bp_tts/tmp > > Would appreciate any advice. > > Thank you, > gen > _______________________________________________ > unit mailing list > unit at nginx.org > https://mailman.nginx.org/mailman/listinfo/unit From info at botpublishing.com Tue Jan 5 20:00:13 2021 From: info at botpublishing.com (Bot-Publishing Inc.) Date: Tue, 5 Jan 2021 15:00:13 -0500 Subject: fresh install configuration problem In-Reply-To: References: Message-ID: Thank you Max. It solved the issue. gen On Tue, Jan 5, 2021 at 2:47 PM Max Romanov wrote: > Hello, > > Most likely it?s a permission issue. Try to specify "user": "ec2-user" for > your "demo" app in configuration. > By default, application starts as "nobody" user and have no permissions to > access files in other users? directories. > > ? > Regards, > Max > > > On 5 Jan 2021, at 16:37, Bot-Publishing Inc. > wrote: > > > > Hello, > > > > I installed the latest Unit package for RHEL 8. > > > > When I try to configure a simple demo app, I am getting: > > > > 2021/01/05 13:27:07 [info] 13694#13694 "demo" application started > > 2021/01/05 13:27:07 [alert] 13694#13694 Python failed to import module > "temp" ModuleNotFoundError: No module named 'temp' > > 2021/01/05 13:27:07 [notice] 13630#13630 process 13694 exited with code 1 > > 2021/01/05 13:27:07 [warn] 13633#13633 failed to start application "demo" > > 2021/01/05 13:27:07 [alert] 13633#13633 failed to apply new conf > > > > The JSON config is as following > > ============================================ > > { > > "listeners": { > > "*:8080": { > > "pass": "applications/demo" > > } > > }, > > "applications": { > > "demo": { > > "type": "python", > > "path": "/home/ec2-user/bp_tts/tmp/", > > "module": "temp", > > "protocol": "wsgi" > > } > > } > > } > > > > temp.py > > ============================================ > > def application(environ, start_response): > > start_response("200 OK", [("Content-Type", "text/plain")]) > > return (b"Hello, Python on Unit!") > > > > > > PWD of temp.py > > ============================================ > > /home/ec2-user/bp_tts/tmp > > > > Would appreciate any advice. > > > > Thank you, > > gen > > _______________________________________________ > > unit mailing list > > unit at nginx.org > > https://mailman.nginx.org/mailman/listinfo/unit > > _______________________________________________ > unit mailing list > unit at nginx.org > https://mailman.nginx.org/mailman/listinfo/unit -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at botpublishing.com Thu Jan 7 00:46:27 2021 From: info at botpublishing.com (Bot-Publishing Inc.) Date: Wed, 6 Jan 2021 19:46:27 -0500 Subject: WSGI HTTP Error Status Message-ID: Hello, I am trying to return an HTTP Error Status 500 under certain conditions, but for some reason 200 status is always returned. Although, the response body is correctly populated. I am using the following code (WSGI python module): =================================================== def application(environ, start_response): try: #... main code except Exception as error: logger.exception(error) start_response( '500', [('Content-Type', 'application/json')]) resp = {"Status": 500, "Error": str(error), "ErrorType": type(error).__name__} else: start_response( '200 OK', [('Content-Type', 'application/json')]) resp = {} #... set response finally: resp = json.dumps(resp, indent=4).encode("utf-8") yield resp ======================================================== Would appreciate any help. gen -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Fri Jan 8 13:23:52 2021 From: vbart at nginx.com (Valentin V. Bartenev) Date: Fri, 08 Jan 2021 16:23:52 +0300 Subject: sane way of cleaning up stale unix sockets? In-Reply-To: References: <4aa7a86a-09cb-cb8a-b6dc-16d53bba4f41@over.ru> <6289051.4vTCxPXJkl@vbart-laptop> Message-ID: <11675957.O9o76ZdvQC@vbart-laptop> No major obstacles, it just waits someone to rewrite the related code. -- Valentin On Tuesday, 5 January 2021 19:19:39 MSK ????????? ?????????? wrote: > Hello > > Why nxt_listen_socket_create is not used to create sockets other than > control? Any positive reason or "still no time to rewrite?" > > -- > > Alex > > On 22.12.2020 17:40, Valentin V. Bartenev wrote: > > Actually we thought about a connection test with the algorithm of atomic > > creation of such sockets, that was implemented earlier this year for the > > control socket: https://hg.nginx.org/unit/rev/0a8840921fd0 > > > > -- > > Valentin > > > > > > > > On Tuesday, 22 December 2020 17:14:15 MSK ????????? ?????????? wrote: > >> Maybe just https://gavv.github.io/articles/unix-socket-reuse/ ? > >> > >> On 22.12.2020 17:12, Valentin V. Bartenev wrote: > >>> On Saturday, 19 December 2020 18:48:02 MSK ????????? ?????????? wrote: > >>>> Hello > >>>> > >>>> Sometimes unitd leaves behind orphaned unix sockets (well, just > >>>> configure it to use some and kill -9!) > >>>> > >>>> On next start, unitd fails to start because of existing sockets. > >>>> > >>>> Is there a sane way to clean up them on start? keeping separate list of > >>>> sockets-to-remove is a clear way to insainty. > >>> [..] > >>> > >>> Hello, > >>> > >>> Indeed, this is a problem. That's the reason why the usage of unix sockets > >>> in listeners is still undocumented. > >>> > >>> It's not so easy to fix, because we need to avoid the situation when the socket > >>> is used by some other processes and avoid any possible race conditions > >>> here. > >>> > >>> Actually, until it will be fixed I have no better idea than put them all in the > >>> same dedicated directory and just clean up everything in it each restart. > >>> > >>> wbr, Valentin V. Bartenev > >>> > >>> > >>> > >>> _______________________________________________ > >>> unit mailing list > >>> unit at nginx.org > >>> https://mailman.nginx.org/mailman/listinfo/unit > >> _______________________________________________ > >> unit mailing list > >> unit at nginx.org > >> https://mailman.nginx.org/mailman/listinfo/unit > >> > > > > > > > > _______________________________________________ > > unit mailing list > > unit at nginx.org > > https://mailman.nginx.org/mailman/listinfo/unit > _______________________________________________ > unit mailing list > unit at nginx.org > https://mailman.nginx.org/mailman/listinfo/unit > From tarkhil at over.ru Fri Jan 8 15:26:10 2021 From: tarkhil at over.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCf0L7QstC+0LvQvtGG0LrQuNC5?=) Date: Fri, 8 Jan 2021 18:26:10 +0300 Subject: sane way of cleaning up stale unix sockets? In-Reply-To: <11675957.O9o76ZdvQC@vbart-laptop> References: <4aa7a86a-09cb-cb8a-b6dc-16d53bba4f41@over.ru> <6289051.4vTCxPXJkl@vbart-laptop> <11675957.O9o76ZdvQC@vbart-laptop> Message-ID: <2ff248a2-d435-7371-b55e-0275ee8f70d6@over.ru> Thanks; I just wanted to be sure I didn't overlook anything -- Alex On 08.01.2021 16:23, Valentin V. Bartenev wrote: > No major obstacles, it just waits someone to rewrite the related code. > > -- > Valentin > > > On Tuesday, 5 January 2021 19:19:39 MSK ????????? ?????????? wrote: >> Hello >> >> Why nxt_listen_socket_create is not used to create sockets other than >> control? Any positive reason or "still no time to rewrite?" >> >> -- >> >> Alex >> >> On 22.12.2020 17:40, Valentin V. Bartenev wrote: >>> Actually we thought about a connection test with the algorithm of atomic >>> creation of such sockets, that was implemented earlier this year for the >>> control socket: https://hg.nginx.org/unit/rev/0a8840921fd0 >>> >>> -- >>> Valentin >>> >>> >>> >>> On Tuesday, 22 December 2020 17:14:15 MSK ????????? ?????????? wrote: >>>> Maybe just https://gavv.github.io/articles/unix-socket-reuse/ ? >>>> >>>> On 22.12.2020 17:12, Valentin V. Bartenev wrote: >>>>> On Saturday, 19 December 2020 18:48:02 MSK ????????? ?????????? wrote: >>>>>> Hello >>>>>> >>>>>> Sometimes unitd leaves behind orphaned unix sockets (well, just >>>>>> configure it to use some and kill -9!) >>>>>> >>>>>> On next start, unitd fails to start because of existing sockets. >>>>>> >>>>>> Is there a sane way to clean up them on start? keeping separate list of >>>>>> sockets-to-remove is a clear way to insainty. >>>>> [..] >>>>> >>>>> Hello, >>>>> >>>>> Indeed, this is a problem. That's the reason why the usage of unix sockets >>>>> in listeners is still undocumented. >>>>> >>>>> It's not so easy to fix, because we need to avoid the situation when the socket >>>>> is used by some other processes and avoid any possible race conditions >>>>> here. >>>>> >>>>> Actually, until it will be fixed I have no better idea than put them all in the >>>>> same dedicated directory and just clean up everything in it each restart. >>>>> >>>>> wbr, Valentin V. Bartenev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> unit mailing list >>>>> unit at nginx.org >>>>> https://mailman.nginx.org/mailman/listinfo/unit >>>> _______________________________________________ >>>> unit mailing list >>>> unit at nginx.org >>>> https://mailman.nginx.org/mailman/listinfo/unit >>>> >>> >>> >>> _______________________________________________ >>> unit mailing list >>> unit at nginx.org >>> https://mailman.nginx.org/mailman/listinfo/unit >> _______________________________________________ >> unit mailing list >> unit at nginx.org >> https://mailman.nginx.org/mailman/listinfo/unit >> > > > > _______________________________________________ > unit mailing list > unit at nginx.org > https://mailman.nginx.org/mailman/listinfo/unit From info at botpublishing.com Fri Jan 8 20:00:06 2021 From: info at botpublishing.com (Bot-Publishing Inc.) Date: Fri, 8 Jan 2021 15:00:06 -0500 Subject: WSGI HTTP Error Status In-Reply-To: References: Message-ID: Please ignore this question. I found the issue - it is not related to the Nginx Unit. On Wed, Jan 6, 2021 at 7:46 PM Bot-Publishing Inc. wrote: > Hello, > > I am trying to return an HTTP Error Status 500 under certain conditions, > but for some reason 200 status is always returned. Although, the response > body is correctly populated. > > I am using the following code (WSGI python module): > =================================================== > def application(environ, start_response): > try: > #... main code > > except Exception as error: > logger.exception(error) > > start_response( > '500', > [('Content-Type', 'application/json')]) > > resp = {"Status": 500, > "Error": str(error), > "ErrorType": type(error).__name__} > > else: > start_response( > '200 OK', [('Content-Type', 'application/json')]) > > resp = {} > #... set response > > finally: > resp = json.dumps(resp, indent=4).encode("utf-8") > yield resp > ======================================================== > > Would appreciate any help. > gen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at bimp.fr Wed Jan 13 09:35:05 2021 From: peter at bimp.fr (Peter TKATCHENKO) Date: Wed, 13 Jan 2021 10:35:05 +0100 Subject: Log rotation? Message-ID: Hello, Is there any way to rotate unit.log without shutdown of the server? I cannot find any information about it in the documentation... Best regards, *Peter TKATCHENKO | Ingenieur Informatique* peter at bimp.fr 150 all?e des Fr?nes - 69760 LIMONEST BIMP Groupe LOGO -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dkplbiiacecokmjc.png Type: image/png Size: 9948 bytes Desc: not available URL: From shahzadkazama at gmail.com Wed Jan 13 10:09:32 2021 From: shahzadkazama at gmail.com (Asma Shahzad) Date: Wed, 13 Jan 2021 15:09:32 +0500 Subject: Log rotation? In-Reply-To: <20210113093507.92AD2497B1D@mail.nginx.com> References: <20210113093507.92AD2497B1D@mail.nginx.com> Message-ID: If i am not wrong then If you are using linux then you can use logrotate utulity to achieve this. On Wed, 13 Jan 2021, 2:35 pm Peter TKATCHENKO, wrote: > Hello, > > Is there any way to rotate unit.log without shutdown of the server? > > I cannot find any information about it in the documentation... > Best regards, > > *Peter TKATCHENKO | Ingenieur Informatique* > peter at bimp.fr > > 150 all?e des Fr?nes - 69760 LIMONEST > > [image: BIMP Groupe LOGO] > _______________________________________________ > unit mailing list > unit at nginx.org > https://mailman.nginx.org/mailman/listinfo/unit -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dkplbiiacecokmjc.png Type: image/png Size: 9948 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dkplbiiacecokmjc.png Type: image/png Size: 9948 bytes Desc: not available URL: From juraj at lutter.sk Wed Jan 13 21:44:49 2021 From: juraj at lutter.sk (Juraj Lutter) Date: Wed, 13 Jan 2021 22:44:49 +0100 Subject: change of polling engine In-Reply-To: <43451925.fMDQidcC6G@vbart-laptop> References: <2750955.e9J7NaK4W3@vbart-laptop> <43451925.fMDQidcC6G@vbart-laptop> Message-ID: <16FF266D-B47B-419D-BF74-2419AA34F4C4@lutter.sk> Hi, > On 10 Dec 2020, at 14:38, Valentin V. Bartenev wrote: > > On Wednesday, 9 December 2020 15:43:05 MSK Juraj Lutter wrote: > [..] >> >> If you could give me some pointer how to debug this properly, I can do it. Or >> I can provide an access to SmartOS zone where someone else could do it. >> > > Let's look to the debug log first: > https://unit.nginx.org/troubleshooting/#debug-log > I finally got to collect the debug logs, you can find it here: https://files.wilbury.net/s/LofKQSjixCWkTNo At 21:35, I curl?d the following to the control socket: curl -X PUT --data-binary '{ "listeners": { "*:8300": { "pass": "applications/php", }, }, "applications": { "php": { "type": "php", "root": "/www/" }, } }' --unix-socket /var/run/unit/control.unit.sock http://localhost/config Then I have waited until 21:37 to kill the process from the terminal (^C). Thanks otis From vbart at nginx.com Mon Jan 18 13:29:19 2021 From: vbart at nginx.com (Valentin V. Bartenev) Date: Mon, 18 Jan 2021 16:29:19 +0300 Subject: change of polling engine In-Reply-To: <16FF266D-B47B-419D-BF74-2419AA34F4C4@lutter.sk> References: <43451925.fMDQidcC6G@vbart-laptop> <16FF266D-B47B-419D-BF74-2419AA34F4C4@lutter.sk> Message-ID: <5426267.DvuYhMxLoT@vbart-laptop> Thanks. I'll inspect the log and let you know if I find the cause or something else is needed. wbr, Valentin V. Bartenev On Thursday, 14 January 2021 00:44:49 MSK Juraj Lutter wrote: > Hi, > > > On 10 Dec 2020, at 14:38, Valentin V. Bartenev wrote: > > > > On Wednesday, 9 December 2020 15:43:05 MSK Juraj Lutter wrote: > > [..] > >> > >> If you could give me some pointer how to debug this properly, I can do it. Or > >> I can provide an access to SmartOS zone where someone else could do it. > >> > > > > Let's look to the debug log first: > > https://unit.nginx.org/troubleshooting/#debug-log > > > > I finally got to collect the debug logs, you can find it here: > https://files.wilbury.net/s/LofKQSjixCWkTNo > > At 21:35, I curl?d the following to the control socket: > > curl -X PUT --data-binary '{ > "listeners": { > "*:8300": { > "pass": "applications/php", > }, > }, > "applications": { > "php": { > "type": "php", > "root": "/www/" > }, > } > }' --unix-socket /var/run/unit/control.unit.sock http://localhost/config > > > Then I have waited until 21:37 to kill the process from the terminal (^C). > > Thanks > otis > > _______________________________________________ > unit mailing list > unit at nginx.org > https://mailman.nginx.org/mailman/listinfo/unit > From juraj at lutter.sk Mon Jan 18 13:44:44 2021 From: juraj at lutter.sk (Juraj Lutter) Date: Mon, 18 Jan 2021 14:44:44 +0100 Subject: change of polling engine In-Reply-To: <5426267.DvuYhMxLoT@vbart-laptop> References: <43451925.fMDQidcC6G@vbart-laptop> <16FF266D-B47B-419D-BF74-2419AA34F4C4@lutter.sk> <5426267.DvuYhMxLoT@vbart-laptop> Message-ID: <80181F14-CA16-4794-950E-EE21E134563C@lutter.sk> > On 18 Jan 2021, at 14:29, Valentin V. Bartenev wrote: > > Thanks. I'll inspect the log and let you know if I find the cause > or something else is needed. > If you need any assistence, just let me know, please. otis From tobias.genannt at kappa-velorum.net Thu Jan 21 12:51:15 2021 From: tobias.genannt at kappa-velorum.net (Tobias Genannt) Date: Thu, 21 Jan 2021 13:51:15 +0100 Subject: Serving Angular + Django with unit Message-ID: <340d55a3-37e6-524f-de06-b0dd98216ac9@kappa-velorum.net> Hello, I'm serving an Angular + Django app with unit. For the most parts this is working fine. The problem I'm having is with deep links and the angular router. All request to paths that are not found should be served the index.html so that the Angular router can activate the matching component. In nginx I would do this with the following: try_files $uri $uri/ /index.html; In unit I'm currently using this: "routes": [ { "match": { "uri": [ "/api/*", "/admin/*" ] }, "action": { "pass": "applications/myapp" } }, { "action": { "share": "/opt/myapp/web", "fallback": { "return": 301, "location": "/" } } } ], With this configuration I'm loosing the path information because of the redirect. Any tips on how to solve the problem? Is there a way to get unit to behave like try_files in nginx? Kind regards, Tobias