search for: execvpe

...l (under an unspecified pathname), (5) the shell shall get "foobar" for its argv[0], and "hello.sh" for its argv[1] (6) we shall see "hello" on the standard output. That's exactly what happens on Linux/glibc. (Note: this result has absolutely nothing to do with my execvpe() implementation, or libnbd in the first place.) Now, according to my above description of the busybox bug, we're tempted to believe that step (6) fails on Alpine Linux (using musl + busybox). We expect the busybox binary to be launched, via the /bin/sh symlink, in step (4), and we expect it t...

These patches have been pushed (f5a065aa3a9c..9075f68ffc8b); I'm posting them for visibility. Laszlo Laszlo Ersek (3): lib/test-fork-safe-execvpe.sh: generalize "run" to "run0" lib/test-fork-safe-execvpe.sh: cope with Alpine Linux / BusyBox limitations Revert "ci: skip "lib/test-fork-safe-execvpe.sh" on Alpine Linux" ci/skipped_tests | 10 ---- lib/test-fork-safe-execvpe.sh | 63...

...ied pathname), > (5) the shell shall get "foobar" for its argv[0], and "hello.sh" for its argv[1] > (6) we shall see "hello" on the standard output. > > That's exactly what happens on Linux/glibc. (Note: this result has absolutely nothing to do with my execvpe() implementation, or libnbd in the first place.) > > Now, according to my above description of the busybox bug, we're tempted to believe that step (6) fails on Alpine Linux (using musl + busybox). We expect the busybox binary to be launched, via the /bin/sh symlink, in step (4), and we e...

On 10/1/19 9:11 AM, Richard W.M. Jones wrote: > On Tue, Oct 01, 2019 at 08:24:33AM -0500, Eric Blake wrote: >>> +#else /* !HAVE_EXECVPE */ >>> + SET_NEXT_STATE (%.DEAD) >>> + set_error (ENOTSUP, "platform does not support socket activation"); >>> + return 0; >>> +#endif >> >> We probably ought to add a matching nbd_supports_socket_activation() >> feature function. &...

On Sun, Mar 19, 2023 at 10:41:37AM +0100, Laszlo Ersek wrote: > This is version 4 of the following sub-series: > > [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe() > [libnbd PATCH v3 10/29] lib/utils: add unit tests for async-signal-safe execvpe() > > http://mid.mail-archive.com/20230215141158.2426855-10-lersek at redhat.com > http://mid.mail-archive.com/20230215141158.2426855-11-lersek at redhat.com > > The Notes section on each patch r...

This is version 4 of the following sub-series: [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe() [libnbd PATCH v3 10/29] lib/utils: add unit tests for async-signal-safe execvpe() http://mid.mail-archive.com/20230215141158.2426855-10-lersek at redhat.com http://mid.mail-archive.com/20230215141158.2426855-11-lersek at redhat.com The Notes section on each patch records the updates for that pa...

...04:59AM +0100, Laszlo Ersek wrote: > On 3/20/23 20:41, Eric Blake wrote: > > On Sun, Mar 19, 2023 at 10:41:37AM +0100, Laszlo Ersek wrote: > >> This is version 4 of the following sub-series: > >> > >> [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe() > >> [libnbd PATCH v3 10/29] lib/utils: add unit tests for async-signal-safe execvpe() > >> ... > > > > Series merged as commit range 742cbd8c7adc..0b7172b3cffa. I see you already fixed one pipeline failure due to some gcc versions being more picky about function...

...gt;> On 3/20/23 20:41, Eric Blake wrote: > >>> On Sun, Mar 19, 2023 at 10:41:37AM +0100, Laszlo Ersek wrote: > >>>> This is version 4 of the following sub-series: > >>>> > >>>> [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe() > >>>> [libnbd PATCH v3 10/29] lib/utils: add unit tests for async-signal-safe execvpe() > >>>> > > ... > >>> > >> > >> Series merged as commit range 742cbd8c7adc..0b7172b3cffa. > > > > I see you already fixed one pipel...

...tprint, but it violates GNU Coding Standards (which state that in general, an application's behavior should not depend on argv[0], precisely so that renaming it doesn't change its behavior). > > So, no, this mess (= Alpine Linux) is not salvageable. The > "lib/test-fork-safe-execvpe.sh" script depends on "expr" being > functional under the name "f". And yes I want "f" to be a > single-character filename; otherwise the nice tabular formatting of the > script falls apart (or produces overlong lines). > > As last step, I learned...

...aszlo Ersek wrote: >> On 3/20/23 20:41, Eric Blake wrote: >>> On Sun, Mar 19, 2023 at 10:41:37AM +0100, Laszlo Ersek wrote: >>>> This is version 4 of the following sub-series: >>>> >>>> [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe() >>>> [libnbd PATCH v3 10/29] lib/utils: add unit tests for async-signal-safe execvpe() >>>> > ... >>> >> >> Series merged as commit range 742cbd8c7adc..0b7172b3cffa. > > I see you already fixed one pipeline failure due to some gcc versions &gt...

This is the error I receive when attempting to start the service. This is from /var/log/messages. Mar 27 11:41:17 portero smb: smbd startup succeeded Mar 27 11:41:17 portero smb: nmbd startup failed Mar 27 11:41:18 portero srvsvcd: execvp: No such file or directory Mar 27 11:41:18 portero smb: srvsvcd startup failed Mar 27 11:41:18 portero wkssvcd: execvp: No such file or directory Mar 27

Per POSIX, execvp() is not safe to call in a child process forked from a multi-threaded process. We can now replace the execvp() call in the child process with a call to our fork-safe (async-signal-safe) variant. Prepare our internal execvpe context on the parent's construction path, use the context in the child, and release the context in the parent on the way out, regardless of whether the handler as a whole succeeded or not. (The context is only a temporary resource.) Signed-off-by: Laszlo Ersek <lersek at redhat.com> Rev...

.../20/23 20:41, Eric Blake wrote: >>>>> On Sun, Mar 19, 2023 at 10:41:37AM +0100, Laszlo Ersek wrote: >>>>>> This is version 4 of the following sub-series: >>>>>> >>>>>> [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe() >>>>>> [libnbd PATCH v3 10/29] lib/utils: add unit tests for async-signal-safe execvpe() >>>>>> >>> ... >>>>> >>>> >>>> Series merged as commit range 742cbd8c7adc..0b7172b3cffa. >>> >>> I see you...

...e: > > execv(<shell path>, { <shell path>, file, argv[1], ..., NULL }) > > In other words, the original argv[0] is not preserved, but is replaced by <shell path>. (Look for _PATH_BSHELL in said historical glibc commit, and also in today's glibc file "posix/execvpe.c".) Aside - what a funny filename, since execvpe() is a glibc extension not in POSIX ;) I've now filed a bug report to the Austin Group: https://www.austingroupbugs.net/view.php?id=1645 And while researching for that, I found that FreeBSD had the same bug up until 2020: https://cgit.fre...

...ation is here: > http://0pointer.de/blog/projects/socket-activation.html > --- > +++ b/generator/states-connect-socket-activation.c > +/* This is baked into the systemd socket activation API. */ > +#define FIRST_SOCKET_ACTIVATION_FD 3 > + > +/* Prepare environment for calling execvpe when doing systemd socket > + * activation. Takes the current environment and copies it. Removes > + * any existing LISTEN_PID or LISTEN_FDS and replaces them with new > + * variables. env[0] is "LISTEN_PID=..." which is filled in by > + * CONNECT_SA.START, and env[1] is &q...

On Wed, Mar 22, 2023 at 03:45:17PM +0100, Laszlo Ersek wrote: > On 3/21/23 18:28, Eric Blake wrote: > > > it is indeed a bug in busybox now that POSIX is moving towards > > standardizing realpath, so I've filed it: > > https://bugs.busybox.net/show_bug.cgi?id=15466 > > I've found another busybox bug. > > The "/bin/sh" utility is provided by

Hi there, I have installed samba-2.2.2 on Redhat linux 7.0 . I have setup the whole server properly and have run the ./configure, make and make install commands successfully. I have even written a basic smb.conf file which is located in /etc/samba . The testparm on the conf file shows no errors. i have checked the /etc/services file for the netbios services and they are all done properly

On 2/21/23 20:32, Eric Blake wrote: > On Tue, Feb 21, 2023 at 07:07:38PM +0100, Laszlo Ersek wrote: >> Well, given Daniel's comments meanwhile, it seems like the original >> execvp() is something we shouldn't fret about. :/ > > glibc marks execvp() and exevpe() as 'MT-Safe env', which means it > does not modify 'environ' and presumably does not use

Hi everybody, I try to convert mbox to maildir using local locations /root/mail is a dir with mboxes /root/INBOX is mbox file h=/root dsync -f -v mirror \ mbox:$h/mail:INBOX=$h/INBOX \ maildir:$h/Maildir:CONTROL=$h/dovecot:INDEX=$h/dovecot \ as result I have dsync(root): Fatal: execvp(mbox:/root/mail:INBOX=/root/INBOX) failed: No such file or directory dsync-local(root): Error:

On Wed, Feb 22, 2023 at 01:47:02AM +0100, Laszlo Ersek wrote: > On 2/21/23 20:32, Eric Blake wrote: > > On Tue, Feb 21, 2023 at 07:07:38PM +0100, Laszlo Ersek wrote: > > >> Well, given Daniel's comments meanwhile, it seems like the original > >> execvp() is something we shouldn't fret about. :/ > > > > glibc marks execvp() and exevpe() as