SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode (was SVN1714 will not run in 'daemon" mode on Solaris8), posted by Stefan Ritt on Wed Nov 8 08:20:34 2006
|
| Steve Jones wrote: | BUG: In the initial comment section of elogd_fancy.cfg the line # This [global] section contains settings common to all logbooks is not parsed correctly as a comment and the embedded [global] is picked up and confuses elogd, eg., elogd will not pickup the port=8080 option. Taking "[global]" out of the comment restores fucntionality. I recommend checking to make sure that the config file checking routine ignores *entire* lines starting with a comment char; |
Acknowledged. The problem was that the section between the line # This [global] section contains settings common to all logbooks and the real [global] section was interpreted as the global section, and thus the "real" one was omitted. I changed the code now such that all lines starting with a '#' or ';' are completely skipped, that fixes the problem. The fix is contained in revision 1745.
| Steve Jones wrote: | ISSUE: The option Logbook dir = causes an enormous amount of problems, and this may be limited to elog installs that exist in NFS space (as opposed to local disk). If the default is left alone elogd appears to work fine; Try and override and the fun begins. The previous attached traces show that once going into daemon mode none of the logbook dirs can be found nor indexed. The workaround is to use the default "logbooks" dir. Perhaps the routine that creates the default (if not found) should be the same as the one that creates the override (?). |
That's weird. Have you tried to specify a full path for the logbook, like /nfs/some/directory ? The only difference of the daemon mode compared to the normal mode is that elogd does a cd to the root ('/'). If you specify logbook dir relative to the starting directory, like 'some/subdir', elogd will the try to access it under '/some/subdir', where it might not have read/write privileges. |
|
SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode (was SVN1714 will not run in 'daemon" mode on Solaris8), posted by Steve Jones on Wed Nov 8 12:55:58 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: | BUG: In the initial comment section of elogd_fancy.cfg the line # This [global] section contains settings common to all logbooks is not parsed correctly as a comment and the embedded [global] is picked up and confuses elogd, eg., elogd will not pickup the port=8080 option. Taking "[global]" out of the comment restores fucntionality. I recommend checking to make sure that the config file checking routine ignores *entire* lines starting with a comment char; |
Acknowledged. The problem was that the section between the line # This [global] section contains settings common to all logbooks and the real [global] section was interpreted as the global section, and thus the "real" one was omitted. I changed the code now such that all lines starting with a '#' or ';' are completely skipped, that fixes the problem. The fix is contained in revision 1745.
| Steve Jones wrote: | ISSUE: The option Logbook dir = causes an enormous amount of problems, and this may be limited to elog installs that exist in NFS space (as opposed to local disk). If the default is left alone elogd appears to work fine; Try and override and the fun begins. The previous attached traces show that once going into daemon mode none of the logbook dirs can be found nor indexed. The workaround is to use the default "logbooks" dir. Perhaps the routine that creates the default (if not found) should be the same as the one that creates the override (?). |
That's weird. Have you tried to specify a full path for the logbook, like /nfs/some/directory ? The only difference of the daemon mode compared to the normal mode is that elogd does a cd to the root ('/'). If you specify logbook dir relative to the starting directory, like 'some/subdir', elogd will the try to access it under '/some/subdir', where it might not have read/write privileges. |
| Quote: | Very weird. No, I did not try an absolute path - but I did notice the attempt to "cd /" in the truss output. In fact, it was immediately after that "cd /" test that things appeared to start not working - basically, elogd could not find anything.
I'm putting this on hold for the time being as I now have test systems going into production. I'll be able to test next week.
|
|
|
SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode, posted by Stefan Ritt on Wed Nov 8 13:07:31 2006
|
| Steve Jones wrote: | | Very weird. No, I did not try an absolute path - but I did notice the attempt to "cd /" in the truss output. In fact, it was immediately after that "cd /" test that things appeared to start not working - basically, elogd could not find anything. |
The "cd /" is mandatory for daemons according to Unix standards. If a daemon gets started on an NFS subtree, that subtree cannot be unmounted anymore. Therefor it's required that all daemons cd to root, such that the NFS subtree can freely be mounted and unmounted. I therefore use absolute paths in all my statements of elogd.cfg. |
SVN1714 will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Mon Sep 18 20:35:44 2006 
|
| On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D" |
SSL does not work, posted by Hisataka YOSHIDA on Fri Jun 5 03:49:20 2020
|
Hello.
I installed the latest elog (3.1.4-2) in CentOS 7, and it is working well without SSL.
When I enalbled SSL option (SSL = 1) in the "elogd.cfg", and tried to start the elogd, the message below was shown and failed to run.
SSL support not compiled into elogd
If I switched the elog to older one (3.1.4-1), I could successeed to run the elogd with SSL option.
Is there any other option required in the latest elog to run with SSL? Or is this bug in the latest version?
Thank you,
Hisataka YOSHIDA |
SSL connection drop with large content, posted by HyonSan Seo on Mon Aug 10 07:56:43 2020
|
Dear all,
I had some difficulty to upload large files (>20MB) with SSL connection. I think it is also related to https://elog.psi.ch/elogs/Forum/68636
During debuging, I found that, when uploading large files, ssl connection is dropped since 'SSL_read' function returns -1.
But it doesn't alway mean broken connection. It may be "SSL_ERROR_WANT_READ".
I changed the "server_loop" function in the source code to "continue" when it is SSL_ERROR_WANT_READ. And it fixed the problem.
Here is my code.
## elogd.c "server_loop" function L30031
if (FD_ISSET(_sock, &readfds)) {
#ifdef HAVE_SSL
if (_ssl_flag){
i = SSL_read(_ssl_con, net_buffer + len, net_buffer_size - len);
if(i<=0){
int ssl_error=SSL_get_error(_ssl_con,i); ## check ssl error code
if(ssl_error==SSL_ERROR_WANT_READ||ssl_error==SSL_ERROR_WANT_WRITE) continue; ## if ssl wants more, continue
}
}
else
#endif
i = recv(_sock, net_buffer + len, net_buffer_size - len, 0);
I am ignorant about networking. Some experts on ssl connection would know a better way to deal with this problem.
Best,
HyonSan Seo
|
SSL, posted by Thomas Kleeb on Wed Apr 11 16:32:22 2012
|
I'm slowly able to see the finish line 
Now all I need to do is get SSL to work. My server name is hf-info-elog and I'm not sure what the correct values for Port= and URL= should be.
thank
Tom (the green-horn) |
SSL, posted by Chris Smyth on Thu Aug 4 14:28:18 2016
|
How do I enable SSL with port 443 in version ELOG V2.7.8-2294 and rename from localhost?
Server is running Windows 2008
We got http://servername:8080 to work and on the network just fine..
but everytime we try to change the port to 443 in global we cant get anything with https:// working
port = 443
ssl = 1
url = https://servername
how do you customize the elog.exe or elogd for windows enviorment to listen on port 443 with specific hostname. please give an example.
Thanks...
|
|