On 20/02/07, Peter <[EMAIL PROTECTED]> wrote:
Maybe I did not get the question. We seem to be talking past each other.
Just read the thread again from the absolute beginning, including the
subject line...
--Amos
On Tue, 20 Feb 2007, Amos Shapira wrote:
You are getting off subject - the original question was about how to find
> out that the other side of a socketpair has closed it.
There is none. That's the point. You can monitor the pid to see if it
went away. Worse if the process becomes a zombie the
On 20/02/07, Peter <[EMAIL PROTECTED]> wrote:
See:
http://www.erlenstar.demon.co.uk/unix/faq_2.html
1.1) last 2 paragraphs and 1.6), 1.7) . Note the part about 'not
confusing inetd' at the end of 1.7). This is almost the problem you
have.
(rest deleted for brevity).
OK, I give up trying
Which pid? The child may very well have forked and exited so the parent is
actually talking to its grand-children, it could also be that multiple
processes are sharing the same socketpair on the other side (that's another
contingency I'll have to take care of).
Then again - if the socketpair()
On 20/02/07, Peter <[EMAIL PROTECTED]> wrote:
> Huh?? When a group leader exits his parent gets SIGCHLD. That's one of
those
> sticky PITA's of UNIX process programming. (I've just double-checked
this
> with a quick program which demonstrate it). The only way I can remember
to
> avoid receving S
On Mon, 19 Feb 2007, Tzahi Fadida wrote:
Essentially you are right that poking a system to see if it is alive can bite
your hand.
I wonder if there is a FOSS event engine out there aside from the one i know
from IBM.
Check out 'watcher' by kenneth ingham. It has a different purpose but it
'
On Monday 19 February 2007 19:22, Peter wrote:
> On Mon, 19 Feb 2007, Tzahi Fadida wrote:
> > I did not understand the current problem, however, just giving my 2c
> > blindly so...:
> > 1. Internet sockets using tcp protocol is the same as using select with a
> > timeout since this is what the tcp
On Mon, 19 Feb 2007, Tzahi Fadida wrote:
I did not understand the current problem, however, just giving my 2c blindly
so...:
1. Internet sockets using tcp protocol is the same as using select with a
timeout since this is what the tcp protocol is doing. Timeouts.
No. The internet sockets have
I did not understand the current problem, however, just giving my 2c blindly
so...:
1. Internet sockets using tcp protocol is the same as using select with a
timeout since this is what the tcp protocol is doing. Timeouts.
2. Can't all this discussion be solved by simply reading the /proc director
On Mon, 19 Feb 2007, Amos Shapira wrote:
Or the timer expires and makes the waiter do some "test and repeat" job,
which falls under my definition of "busy wait" (even if it gets to rest for
a while between iterations).
The wait consists in yielding. The process spends user time only while
no
On 18/02/07, Peter <[EMAIL PROTECTED]> wrote:
On Sun, 18 Feb 2007, Amos Shapira wrote:
>> That's why you must use both a reaper and select() with timeout.
>
> What's the point of select(2) with a timeout? How long should the
timeout be
> set and what should be checked when it's reached? Why wo
On 18/02/07, Shachar Shemesh <[EMAIL PROTECTED]> wrote:
Baruch Even wrote:
> You want to avoid another case of race condition.
>
I think Amos intended to simply call "exit" from the signal handler, so
that problem would not be an issue. However:
Indeed.
Without a select you will have code l
On Sun, 18 Feb 2007, Amos Shapira wrote:
That's why you must use both a reaper and select() with timeout.
What's the point of select(2) with a timeout? How long should the timeout be
set and what should be checked when it's reached? Why wouldn't a child
reaper be enough in the situation Baruc
Baruch Even wrote:
> You want to avoid another case of race condition.
>
I think Amos intended to simply call "exit" from the signal handler, so
that problem would not be an issue. However:
> Without a select you will have code like:
>
> handle_sigchld() { dead_child=1; wait(); }
> dorecv() {
>
* Amos Shapira <[EMAIL PROTECTED]> [070218 05:18]:
> On 17/02/07, Peter <[EMAIL PROTECTED]> wrote:
> >
> >
> >On Fri, 16 Feb 2007, Baruch Even wrote:
> >
> >> You assume that the signal was received in the recv() call, you'll have
> >> a race condition where a child might die just before you go int
On 17/02/07, Peter <[EMAIL PROTECTED]> wrote:
On Fri, 16 Feb 2007, Baruch Even wrote:
> You assume that the signal was received in the recv() call, you'll have
> a race condition where a child might die just before you go into recv()
> and the child is never reaped. The chance might be small t
On 16/02/07, Tzahi Fadida <[EMAIL PROTECTED]> wrote:
Is there an added value in contrast of just using a simple
server that accepts on low ports but bounces the packets
to a low privileged port?
Examples:
1. A daemon for which you don't have the source and which you can't
configure to use no
On 16/02/07, Shachar Shemesh <[EMAIL PROTECTED]> wrote:
Baruch Even wrote:
> If it is a process parent/child pair then you could listen on the signal
> SIGCHLD and when the child exits your process will be notified by the
> kernel.
Well, no.
The most obvious programs that will be run through pr
On Fri, 16 Feb 2007, Tzahi Fadida wrote:
Is there an added value in contrast of just using a simple
server that accepts on low ports but bounces the packets
to a low privileged port?
The easy way to do this was discussed before, it's called port
forwarding. It's done at the firewall level. S
On Fri, 16 Feb 2007, Baruch Even wrote:
You assume that the signal was received in the recv() call, you'll have
a race condition where a child might die just before you go into recv()
and the child is never reaped. The chance might be small to miniscule
but it's still there.
That's why you mu
On Fri, 16 Feb 2007, Amos Shapira wrote:
Digging a bit more in the kernel source I see that since the SOCK_DGRAM
sockets are not connected, closing one side won't bother to inform the other
side about the shutdown. Switching to SOCK_SEQPACKET solved the problem.
This means that privbind will d
Is there an added value in contrast of just using a simple
server that accepts on low ports but bounces the packets
to a low privileged port?
Also, again of curiosity :), is there a way to wrap the daemon
without forking and replacing the bind call with a customized bind
with a more detailed securi
* Shachar Shemesh <[EMAIL PROTECTED]> [070216 12:10]:
> Baruch Even wrote:
> > If it is a process parent/child pair then you could listen on the signal
> > SIGCHLD and when the child exits your process will be notified by the
> > kernel.
> Well, no.
>
> The most obvious programs that will be run t
Tzahi Fadida wrote:
> On Friday 16 February 2007 03:07, you wrote:
>
>> Hi,
>>
>> I'm trying to help complete Shachar Shemesh' privbind project (
>> http://sourceforge.net/projects/privbind) and it mostly works except that
>>
>
> Just from curiosity, what does it mean privileged socket? why
On Friday 16 February 2007 03:07, you wrote:
> Hi,
>
> I'm trying to help complete Shachar Shemesh' privbind project (
> http://sourceforge.net/projects/privbind) and it mostly works except that
Just from curiosity, what does it mean privileged socket? why are they
privileged for internal use.
I
Baruch Even wrote:
> If it is a process parent/child pair then you could listen on the signal
> SIGCHLD and when the child exits your process will be notified by the
> kernel.
Well, no.
The most obvious programs that will be run through privbind are daemons.
Those tend (I say "tend", but it's in t
On 16/02/07, Shamir Udi <[EMAIL PROTECTED]> wrote:
off course they are not, they are UDP.
Where is UDP involved, except maybe in spirit?
These are not network sockets, they are anonymous unix-domain sockets which
means that the connection is reliable and that the kernel can tell when
there i
On 16/02/07, Baruch Even <[EMAIL PROTECTED]> wrote:
If it is a process parent/child pair then you could listen on the signal
SIGCHLD and when the child exits your process will be notified by the
kernel. You'll need to wait() on the child process in the signal handler
to reap the zombie child pro
off course they are not, they are UDP.
On 2/16/07, Amos Shapira <[EMAIL PROTECTED]> wrote:
On 16/02/07, Amos Shapira <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm trying to help complete Shachar Shemesh' privbind project
(http://sourceforge.net/projects/privbind
> ) and it mostly works except th
* Amos Shapira <[EMAIL PROTECTED]> [070216 03:17]:
> Hi,
>
> I'm trying to help complete Shachar Shemesh' privbind project (
> http://sourceforge.net/projects/privbind) and it mostly works except that
> when the writing side of the socketpair exits, the side which calls
> "recvfrom" keeps waiting
On 16/02/07, Amos Shapira <[EMAIL PROTECTED]> wrote:
Hi,
I'm trying to help complete Shachar Shemesh' privbind project (
http://sourceforge.net/projects/privbind) and it mostly works except that
when the writing side of the socketpair exits, the side which calls
"recvfrom" keeps waiting for mes
Hi,
I'm trying to help complete Shachar Shemesh' privbind project (
http://sourceforge.net/projects/privbind) and it mostly works except that
when the writing side of the socketpair exits, the side which calls
"recvfrom" keeps waiting for messages.
I couldn't find anything which suggests that I'
32 matches
Mail list logo