<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: CIPE Logging/Running in the foreground
From: "Keith E Smith" <keith,AT,ksmith,DOT,com>
Date: Tue, 22 Jan 2002 18:03:00 +0100

Groovy.  Got it running.  It seems to work well.

Two questions/thoughts:

1) Why is there so much console/syslog output?  According to the doc the
program logs as LOG_DAEMON.  Might try re-compile with LOG_LOCAL1 |

cipcb0: cipe_recvmsg
cipcb0: cipe_sendmsg

Scrolling on my console screen, and filling the logs.  I'm a firm believer
that there is no such thing as too much logging.  On the other hand I'm also
a firm believer in being able to turn it off & down.  I loaded the module
with cipe_debug=0.  Still noisy as hell.

These are pretty intertwined in the code in dprintk's.  I guess I'll have to
hack them out through that routine.

2) There is no way to force the ciped-cb process to stay in the forground
without using debug, which generates even more output.  That is until I
hacked a '-f' option in. :)

Why would I want this? you ask.  Several reasons.  If <gasp> a bug were to
kill a ciped-cb process I'd like to know and be able to restart it.

The simplest way to do this is in inittab:

cp00:345:respawn:/usr/local/sbin/ciped-cb -f -o /etc/cipe/peers/bam-bam

Also this way if you suspect a problem you can just kill it and it restarts
by itself.  System shutdown is automagic.

It simplifies the writing of a controlling wrapper program.  You can have a
daemon kick them off and manage multiple ciped processes without having to
constantly poll them, or check for run locks and the like.  Just sleep/wait

PKCIPE amplifies this issue even more.

Anybody addressed either of these issues in some trivial fashion I've
Keith Smith                  keith,AT,ksmith,DOT,com
655 W Fremont Dr
Tempe AZ 85282               Arizona is Hot!

<< | Thread Index | >> ]    [ << | Date Index | >> ]