Forking - a few queries

From: Julian Buckley (s348266@student.uq.edu.au)
Date: 01/10/00


Hello all,

I was wanting some technical advice if the following is the "better way"
of performing something like this.  I tested it with a 50MB temp file,
and whilst it took about 40 secs to finish up, it didn't lag the mud out
nor block it.  So at least it did what I wanted it to, sorta...

Now, the code simply scans the syslog.* files (syslog.1, syslog.2, etc)
for occurrences of 'SYSERR' and counts the number of lines
accordingly...

***START***
void syserr_check(struct char_data *ch)
{
  FILE *fl;
  char line[256];
  int count = 0;

  if (fork() != 0)
    return;

  sprintf(buf, "nice grep SYSERR ../log/syslog.* > ../log/syserr.tmp");
  system(buf);

  if (!(fl = fopen("../log/syserr.tmp", "r"))) {
    perror("Fatal error opening syserr.tmp!");
    exit(1);
  }

  while (!feof(fl)) {
    get_line(fl, line);
    count++;
    continue;
  }
  count--;

  if (count) {
    sprintf(buf, "\007\007\007\007&rThere are %d SYSERRs in the system
logs requiring attention.&n\r\n", count);
    send_to_char(buf, ch);
  }
}
***END***

My queries were...:
1) When I throw "exit(0)" at the end of the function (as per Daniel's
email on a similar topic last week), the function runs but no output
returns to the mud.  How can you make it return the data to the mud?
2) On the flip side, if I leave it out - output gets returned, but
"bin/circle" is childed each time I login, meaning when sending a
SIGHUP,
it appears twice, or thrice, etc - obviously the function doesn't close
until exit() is called...;
2) When fork()-ing, is it okay to leave a nice() call there, or is it
redundant?;
3) Is there an easier way to perform the above, or is get_line-ing okay?



Thanks in anticipation,
-Caniffe


     +------------------------------------------------------------+
     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html  |
     +------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 04/10/01 PDT