Has anyone had issues with having too many files open? I'll setup my server and let it go but after a while, I end up with a lot of "cannot create socket: Too many open files" errors being reported.  I have a sync to another e-log going which I suspect is part of the cause since that e-log server hasn't had this issue. I suspect that there are files being opened, going into some return loop code and then never getting closed. I'm not a C programmer but I see lines like :

fh = open(tmp_filename, O_RDONLY);
      if (fh > 0) {
         read(fh, result, size - 1);
         close(fh);
      }

      /* remove temporary file */
      remove(tmp_filename);

This looks like it opens the file but unless the remove function closes the file, it will remain open even through the file has been deleted. Maybe this isn't the correct behaviour of 'remove' and I am mistaken?

There are also parts like :

 fh = open(textfile, O_RDONLY | O_BINARY);
      if (fh < 0) {
         printf("Message file \"%s\" does not exist.\n", textfile);
         return 1;
      }

      size = (INT) lseek(fh, 0, SEEK_END);
      lseek(fh, 0, SEEK_SET);

      if (size > (INT) (sizeof(text) - 1)) {
         printf("Message file \"%s\" is too long (%zd bytes max).\n", textfile, sizeof(text));
         return 1;
      }
This looks like for the second error, it will complain that the file is too long, return an error message but not close the file and would leave it open. Is this a reasonable avenue to pursue or am I mis-reading the code?   Thanks.

The code segements you show are from the command line tool elog.c, not the server elogd.c. The tool is called to submit a new message from the command line. Even if there would be a file not properly closed, it will be closed by the operating system once the program finishes. So no problem of too many open files there.

We have a number of temperature chambers – each has its own laptop running a local ELOG server, with unique logbook for each.  Using the mirror feature, these individual logbooks periodically synchronize to a single remote desktop server, which has a copy of each of the logbooks.  All of that works great, as long as each of the ELOG servers are storing the logbook(s) to their respective local hard drive.

I wanted the remote server to store its copy of the logbooks on the network file server.  I changed the global options of the elogd.cfg file, adding the following:

               Logbook dir = S:\SHARED\LOGBOOKS

That change worked fine on the remote desktop server – new logbook entries were now being stored on the network file server.

Unfortunately, I lost the ability to sync from the individual logbooks to the remote desktop server.  During synchronization, I now get the following error message: “Error sending local entry: Error transmitting message". 

Has anyone run into this? Does this make sense? Am I missing something? Is there a workaround? Is there a wrong time to drink beer?

Thanks,

Frank

Sounds really strange to me. The remote server does not "know" that "S:\" is a network drive, so the syncing process should work exactly as before. The only idea I have is that the access to the network files take pretty long, and you run into a timeout during syncing. We had this in the past (for AFS netwhor shares, not Windows shares), where sometimes we have a blocking behaviour where the file access lasted 10-20 seconds, and the server process was simply blocked. Since then I do not recommend to put logbook on network shares.

Stefan

First, thank you so much for elog;
after using it for about 3 years, it has proven really handy and reliable.

When there is a very long URL in a message in "plain" encoding,
and this message is displayed in a list of messages,
a very long scrollbar appears at the bottom (same "scroll width" as the URL)
and some tabs and and dropdowns (filters) are unreachable without scrolling.

This does not happen if

• the message is displayed in single message page
• the message has a ELCode encoding

The exact version used is
0b9f7ed0 Merge branch 'develop'

There are no relevant instructions in elog.css for .messagelist,
and I did not find any obvious fix in the source code.