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.
