Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 06 Jan 2020 18:18:21 +0100
From:      Peter <peter@citylink.dinoex.sub.org>
To:        freebsd-stable@FreeBSD.ORG
Subject:   Re: session mgmt: does POSIX indeed prohibit NOOP execution?
Message-ID:  <op.0dzecvaraas8k8@localhost>
References:  <op.0dxynipoaas8k8@localhost> <20200106001057.GA64665@elch.exwg.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 06 Jan 2020 01:10:57 +0100, Christoph Moench-Tegeder  
<cmt@burggraben.net> wrote:

>> When a program is invoked via /usr/sbin/daemon, it should already be
>> session leader AND group leader, and then the above code WOULD be a
>> NOOP, unless POSIX would require the setpgid() to fail and thereby the
>> program to abort - which, btw, is NOT a NOOP :(
>
> https://pubs.opengroup.org/onlinepubs/9699919799/
>  "The setpgid() function shall fail if: [...] The process indicated by  
> the
>   pid argument is a session leader."

Okay, so, what You are saying is that I got correct information insofar  
that POSIX indeed demands the perceived behaviour. Thanks for that  
confirmation.

> Not much room to argue?

Why that? This is not about laws you have to follow blindly whether you  
understand them or not, this is all about an Outcome - a working machine  
that should properly function.
So either there are other positive aspects in this behaviour that weight  
against the perceived malfunction, or the requirement is simply wrong. And  
the latter case should be all the argument that is needed.

I do not say disobey Posix. I only say that one of the involved parts must  
certainly be wrong, and that should be fixed. So if You are saying, the  
problem is in Posix, but we are in the role of blind monkeys who have to  
follow that alien commandment by all means no matter the outcome, then  
this does not seem acceptable to me. Actually, as it seems to me, this  
whole session thing came originally out of Kirk McKusick's kitchen and  
made its way from there into Posix, so if there is indeed a flaw in it, it  
should well be possible to fix it going the same way.

In any case, this here (to be found in /etc/rc,d/kadmind) is a crappy  
workaround and not acceptable style:
>        command_args="$command_args &"

We aren't slaves, or, are we?

I for my part came just accidentially across this matter, and as my stance  
is, 1. the code has to be solid enough to stand the Jupiter mission, and  
therefore 2. do a rootcause Always, on Every misbehaviour (and then fix it  
once and for all), so I figured that thing out.

rgds,
PMc



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.0dzecvaraas8k8>