Re: Can't launch apps, fork() returns ENOMEM

[Simon McVittie]

On Wed, 11 Apr 2018 at 14:02:57 -0600, Daniel Drake wrote:
> I was wrong in thinking that gspawn lets you say "run this binary, and
> here's the fd that you should use for stdout".

The interface for that is the newer GSubprocess and GSubprocessLauncher.

> So, in order to avoid needing gnome-shell's app_child_setup(), we
> would either need to extend the gspawn API to allow specific file
> descriptors to be passed in, or perhaps another option to consider is
> to have gdesktopappinfo call posix_spawn directly (instead of gspawn).

... or make GDesktopAppInfo use GSubprocess instead of g_spawn, and
have a way for GSubprocess to use posix_spawn instead of g_spawn
in the (hopefully common) case where its ChildData.child_setup_func
is NULL.

smcv
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Can't launch apps, fork() returns ENOMEM

[Daniel Drake]

Spotted another complication here.

On Mon, Apr 2, 2018 at 1:15 PM, Daniel Drake  wrote:
> Then I considered making glib just call posix_spawn() directly when
> appropriate. There are a number of things in that API which let
> relevant actions be done in the child process before it does the exec
> - managing file descriptors, signal handlers, etc. The big issue there
> is that glib lets you pass an arbitrary GSpawnChildSetupFunc to be run
> in the child before the exec(), this is used by gnome-shell, and there
> is no equivalent hook in posix_spawn().
>
> In gnome-shell app_child_setup() this function is used to send stdout
> and stderr to journald. Also in glib gdesktopappinfo.c child_setup()
> the same mechanism is used to set GIO_LAUNCHED_DESKTOP_FILE_PID in the
> child process to it's own process PID (can't find the background
> here).
>
> I think there are 2 viable paths forward:
>
>  1. Eliminate the child_setup calls from these codepaths to allow
> posix_spawn() to be used. The gspawn code already allows for file
> descriptor redirection but this would have to be exposed via
> additional parameters to g_desktop_app_info_launch_uris_as_manager() -
> an API change.

I was wrong in thinking that gspawn lets you say "run this binary, and
here's the fd that you should use for stdout".

The parameters that exist in the current interfaces either let you
inherit stdin/out/err from the parent, or create an entirely new pipe
in each case.

So, in order to avoid needing gnome-shell's app_child_setup(), we
would either need to extend the gspawn API to allow specific file
descriptors to be passed in, or perhaps another option to consider is
to have gdesktopappinfo call posix_spawn directly (instead of gspawn).

Daniel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Can't launch apps, fork() returns ENOMEM

[Alan Coopersmith]

On 04/ 2/18 12:15 PM, Daniel Drake wrote:
> Discussions here have lead to glibc's posix_spawn() being recently
> reimplemented to use clone(CLONE_VM) while solving practically all the
> danger there.

We've done something similar in the Solaris libc recently, so I'd
support using posix_spawn if possible.

> Then I considered making glib just call posix_spawn() directly when
> appropriate. There are a number of things in that API which let
> relevant actions be done in the child process before it does the exec
> - managing file descriptors, signal handlers, etc. The big issue there
> is that glib lets you pass an arbitrary GSpawnChildSetupFunc to be run
> in the child before the exec(), this is used by gnome-shell, and there
> is no equivalent hook in posix_spawn().
> 
> In gnome-shell app_child_setup() this function is used to send stdout
> and stderr to journald. Also in glib gdesktopappinfo.c child_setup()
> the same mechanism is used to set GIO_LAUNCHED_DESKTOP_FILE_PID in the
> child process to it's own process PID (can't find the background
> here).
> 
> I think there are 2 viable paths forward:
> 
>  1. Eliminate the child_setup calls from these codepaths to allow
> posix_spawn() to be used. The gspawn code already allows for file
> descriptor redirection but this would have to be exposed via
> additional parameters to g_desktop_app_info_launch_uris_as_manager() -
> an API change. If GIO_LAUNCHED_DESKTOP_FILE_PID can't be reimplemented
> another way then we could first exec a binary wrapper that sets this
> env variable before execing the app itself.

This also seems like the better path to me.  It does seem strange that
you need to set an environment variable in the child process to tell
it what it's PID is - perhaps it's for children of that child to find
the spawn point of their family?

>  2. Propose to http://www.opengroup.org/austin/ that posix_spawn()
> grows the capability to call a user-specified child setup func. There
> is some unused padding in posix_spawnattr_t which could be used to
> store the function pointer and data pointer. Then implement this in
> glibc. I guess this is a lengthy process and it's not a great idea
> from the glibc standpoint where such code would run in dangerous
> context.

The Austin Group does not like specifying API that no one has yet
implemented and proven to be working and useful - they'd rather you
get one of the Linux, BSD, or Unix libc's to first implement and show
the design works, then standardize it.

-- 
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list