messages stay in the tube after a server crashe. (with bash)

I use a shell bash to verify my resource manager, for example, I type:
echo “param1” >/dev/DataServer/parameter_name

If my ‘res-mugger’ :wink: crashes, without replying to my client,
subsequent above command will be concaneted.
My resource manager will receive “param1param1” then
“param1param1param1”, etc. even if I reply to these subsequent messages.

So, I have to exit and restart a new shell.

It seems that problem occur only when the client is bash.


Alain.

Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:

I use a shell bash to verify my resource manager, for example, I type:
echo “param1” >/dev/DataServer/parameter_name

If my ‘res-mugger’ > :wink: > crashes, without replying to my client,
subsequent above command will be concaneted.
My resource manager will receive “param1param1” then
“param1param1param1”, etc. even if I reply to these subsequent messages.

Hmmm … you mean that you resource manager is no longer running and
the shell doesn’t note the error? What if you use /bin/echo instead
of the built-in.

So, I have to exit and restart a new shell.

It seems that problem occur only when the client is bash.

This seems to be very odd. I’ve never seen something like this
before. It isn’t your resmgr printing to the console or something
is it?

Thomas

Thomas Fletcher a écrit :

Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
I use a shell bash to verify my resource manager, for example, I type:
echo “param1” >/dev/DataServer/parameter_name

If my ‘res-mugger’ > :wink: > crashes, without replying to my client,
subsequent above command will be concaneted.
My resource manager will receive “param1param1” then
“param1param1param1”, etc. even if I reply to these subsequent messages.

Hmmm … you mean that you resource manager is no longer running and
the shell doesn’t note the error? What if you use /bin/echo instead
of the built-in.

So, I have to exit and restart a new shell.

It seems that problem occur only when the client is bash.

This seems to be very odd. I’ve never seen something like this
before. It isn’t your resmgr printing to the console or something
is it?

Thomas

My problem is that I didn’t really understand how to reply an error to a
client.

Here is a snippet code (server):
int io_write(resmgr_context_t *ctp, io_write_t *msg, RESMGR_OCB_T *ocb)
{
int nbytes, fd_dup = NULL, return_value = EOK;
unsigned key, nb_car;
char *buffer, *buffer_read, *buffer_p;
data_hash_t *data_hash = NULL;

if ((status = iofunc_write_verify(ctp, msg, ocb, NULL)) != EOK) {
return(status);
}

// forget special xtypes

nbytes = msg->i.nbytes;
if ((buffer = malloc(nbytes)) == NULL) {
return(errno);
}

if (resmgr_msgread(ctp, buffer, nbytes, sizeof(msg->i)) == -1) {
free(buffer);
return(errno);
}

// strip ‘\n’ at the end of the name
if (buffer[nbytes-1] == ‘\n’) {
buffer[nbytes-1] = ‘\0’;
}

key = 0;

switch (((iofunc_ocb_t *)ocb)->attr->device) {
case PARAMETER_KEY:
key = atoi(buffer);
hashEntryDataBase = Tcl_FindHashEntry(key_hash_table, (char *)key);
if (hashEntryDataBase) {
// get the name hashEntryDataBase value
hashEntryDataBase = (Tcl_HashEntry
*)Tcl_GetHashValue(hashEntryDataBase);
} else {
log_recoverable_error("%s: ask for a bad key %s\n", EINVAL);
return_value = EINVAL;
break;
}


default:
return_value = ENOSYS;

// Ok, we can release the record buffer structure
pthread_rwlock_unlock(&resmgr_record_buffer_rwlock);

pthread_mutex_lock(&record_access_mutex);
data_hash->in_access = NO_ACCESS;
// Here, somebody way wait for the condvar, so we signal that the
record is free for any access.
pthread_cond_broadcast(&record_access_cond);
pthread_mutex_unlock(&record_access_mutex);
free(buffer_read);
close(fd_dup);
break;
}

_IO_SET_WRITE_NBYTES(ctp, nbytes); // indicate how many byte we wrote

if (msg->i.nbytes > 0)
((iofunc_ocb_t *)ocb)->attr->attr.flags |= IOFUNC_ATTR_MTIME |
IOFUNC_ATTR_CTIME;

free(buffer);

return(return_value);
}

It seems that each time I return a value different from EOK, my client is
unblocked but the message stay in the tube!

What’s wrong?

Thanks,
Alain.