Developing "linux-only" software right now -- is it a "bad thing"?

[zirias@]

Well, what do you think? Problem is, I have a linux-based router/firewall and sometimes (every few months) the NIC driver goes crazy ... I have no idea whether this is a hardware problem or just a bug in the driver. But what helps is restarting the networking ...

To automate this, I'm building a daemon right now that can monitor logfiles and watch out for patterns, given as perl compatible regular expressions. If a pattern matches, it should execute a corresponding action, for example a shell script.

Right now, this is work in progress, but I plan to use Linux' inotify API for monitoring the logs.

So in fact, this is two questions: First, what do you think about writing software, that is tied to ONE operating system, just because of some implementation detail? And second: DO I have alternatives? Is there a C library I don't know, that abstracts filesystem monitoring in a platform-independent way?

 

[Cthulhux]

First, what do you think about writing software, that is tied to ONE operating system, just because of some implementation detail?

Generally speaking: Bad concepts usually lead to bad implementations of them.

DO I have alternatives?

Don't tie yourself up some restricted platform APIs.

 

[tobik@]

Is there a C library I don't know, that abstracts filesystem monitoring in a platform-independent way?

https://github.com/emcrisostomo/fswatch

 

[SirDice]

Is there a C library I don't know, that abstracts filesystem monitoring in a platform-independent way?

Gamin/FAM perhaps?

devel/fam
devel/gamin

With Perl you could also do something like this:

open(MESSAGES,"tail -F /var/log/messages|");
while(<MESSAGES>) {
  # Do some stuff here
}

The tail -F works similar to tail -f but it will reopen the file when it's renewed (due to log rotation for example).

 

[zirias@]

Generally speaking: Bad concepts usually lead to bad implementations of them.
Don't tie yourself up some restricted platform APIs.

This, by itself, is not that helpful, because the main reason here ist there's no standard for file monitoring ("polling" stat() is not what I want to do...), instead very different platform-specific APIs. I didn't design them But I share your opinion, that's why I was asking whether it's really a "bad thing" -- at least if the only alternative would have been to implement code for ALL the APIs myself. So ...

https://github.com/emcrisostomo/fswatch

This comes very handy, looks like exactly the kind of project I was looking for, I'll definitely have a look at it! Maybe this will be a platform-independet daemon in the end

With Perl you could also do something like this:

open(MESSAGES,"tail -F /var/log/messages|");
while(<MESSAGES>) {
  # Do some stuff here
}

This was roughly my first code (just not the capitalized F), but there was a different problem. Terminating on SIGTERM wouldn't work that way. perl (depending on the version) somehow automatically restarts a read using <> after handling a signal and I found no way to change this behavior. What's working for me now is a solution with the following open:

sub openTail {
  my ($r, $w) = POSIX::pipe();
  my $pid = fork();

  if ($pid < 0) {
    die "fork: $!";
  } elsif (!$pid) {
    POSIX::close($r);
    POSIX::dup2($w, 1);
    exec ($tail, "-n0", "-f", $logfile);
  }
  POSIX::close($w);
  return ($pid, $r);
}

and the following main loop:

sub watchTail {
  my $tailfd = shift;
  while ($running && POSIX::read($tailfd, $_, 1024)) {
    if (/kernel:.*NETDEV\s+WATCHDOG:\s+eth0/) {
      restartNetworking();
    }
  }
}

While this works as expected (POSIX::read() really returns with EINTR after handling a signal), it doesn't look too much like perl any more AND it already took me so much time to find this solution that I thought -- why not generalize the problem and create a "real" daemon

 

[DutchDaemon]

Kindly wrap this topic up: https://forums.freebsd.org/threads/freebsd-forums-rules.38922/, rule #7.

 

[zirias@]

The technical aspects of this topic are about how to make it portable, so where's the problem? Do we really need these meta-posts here?

 

[kpa]

Do you intend to publish your solution? If not I don't see why you worry so much about the portability of it. I have written heaps of software for my own use but I have given zero thought about its portability because I know I won't be using it outside FreeBSD.

If inotify does the job then why not use it?

 

[zirias@]

Well, it's published as a side effect of me using github to store the source. And I just think if there is an easy way to make it portable (this libfswatch really looks promising), I might profit later when I need something similar on a different OS. But my first thaught WAS to just stick with inotify, as I didn't find ready-to-use solutions that abstract it away.

On a side note, when I see that a specific problem I face can be generalized, I sometimes take it as an opportunity to get some training