Well, it was worth a shot and is giving me some ideas to try. (I just tested this myself too, just to be sure it wouldn't work.)
On Wednesday, June 8, 2022 at 8:24:44 PM UTC-4 mmer...@gmail.com wrote: > Well I might have answered too hastily. Seems the first process is > controlled by fabric and not virtualenv. > > - Michael > > On Jun 8, 2022, at 19:23, Michael Merickel <mmer...@gmail.com> wrote: > > I doubt you’ll have the same problem with “python -m > pyramid.scripts.pserve dev_admin.ini” but would be good to find out. The > process list appears to be due to the virtualenv wrapper around a console > script which this should skip. > > > > - Michael > > On Jun 8, 2022, at 15:31, 'Jonathan Vanasco' via pylons-discuss < > pylons-...@googlegroups.com> wrote: > > I doubt anyone here may have experienced this, but I've run out of > resources to explore on this... > > We use Fabric (fabfile.org) to automate a lot of things. It is great. > > I built a new routine in it this week, and I can't get it to clean up > properly. The routine simply spins up an admin version of a pyramid app, > then hits some API endpoints to POST some filesystem data to it. > > This is executed in a virtualenv. The problematic part of the routine is > roughly... > > @task > def import_data(c): > with c.cd("localpath/to/pyramid_app"): > proc_server = c.run("pserve dev_admin.ini", replace_env=False, > asynchronous=True) > > The issue is that I see two different processes on the operating system: > * cd localpath/to/pyramid_app && pserve dev_admin.ini > * /Library/Frameworks...Python /virtualenv/bin/pserve dev_admin.ini > > asynchronous is used because running pyramid would otherwise block > forever. i just analyze the process stderr for the "Serving" line, and > continue once it is emitted. > > In fabric, I can access the FIRST process via `proc_server.runner` and I > can stop/kill/terminate that -- but that leaves the second process > running. That second process is one PID higher, and is the actual process > that is running Pyramid and bound to the ports. > > I have a temporary workaround where I increase the PID by 1 and > `c.run("kill %s" % pid2)` that process, but this is janky. > > Has anyone encountered this before or have an idea on how to better handle > this? > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to pylons-discus...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/45ca3e17-e8a7-459a-ac69-492b3fadaeccn%40googlegroups.com > > <https://groups.google.com/d/msgid/pylons-discuss/45ca3e17-e8a7-459a-ac69-492b3fadaeccn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/30f90196-e89c-45fb-8ae0-3918a63f4768n%40googlegroups.com.