Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 647 of 808  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Icon Author Author Email Categorydown OS ELOG Version Subject
  2039   Fri Nov 3 14:40:36 2006 Reply David Spindlerdsspindler@gmail.comBug reportWindows2.6.2-1734Re: Bug? Password file location changed

Steve Jones wrote:

David Spindler wrote:

David Spindler wrote:
I just tried to upgrade from 2.6.1-1633 to 2.6.2-1734. Whenever I tried to access the elog, it showed my password to be invalid. I tried this on 2 machines and same results. I did notice on the second one when I started it from a command prompt that it was creating a new empty password file in a different location.

I have a password file called pwd.txt. It resides in the main elog directory, in my case, c:\elog, along with the elgod.exe and elogd.cfg. Apparently, the new version looks for it in the logbooks directory. I adjusted my path to the file and it works fine.

I am reporting this as a bug because it is my guess that this is not an expected result. I would expect the old elogd.cfg file to work without altering in the newer version.

Thanks, keep up the great work, Stefan. You have a great program.
David Spindler

I also just noticed that the text files I use for presetting the text window also have to be in the logbooks directory.



Quote:
The relocation was a documented change that Stefan made intentionally. Yes, it caught me too Smile

Thanks. I checked the changelog and the documentation for any such changes but did not see them. I just looked again, and still do not see them. Anyway, I know what to expect, now, and will adjust. Again, thanks!
  2048   Tue Nov 7 09:22:52 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportWindows2.6.2-1734Re: Bug? Password file location changed

David Spindler wrote:
Thanks. I checked the changelog and the documentation for any such changes but did not see them. I just looked again, and still do not see them. Anyway, I know what to expect, now, and will adjust. Again, thanks!


That change was actually made in SVN revision 1708 on Aug. 1st, 2006, which was after the release of 2.6.2. So it will be made official in 2.6.3 and documented accordingly.
  2049   Wed Nov 8 07:59:01 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportWindowsV2.6.2-172Re: checkbox

deletoille wrote:
I found a small Bug when I create an entry. I activate a checkbox (attachement1) but when I upload a file, the activation disappears (attachement 2). I have to activate again the checkbox.
Is it something I can do?


I tried with V2.6.2-1741 and the problem was not there. It was fixed some time ago, so it should have worked in 1723 as well. Can you try the minimal example coming with the distribution, just by adding one MOptions attribute, like:
[global]
port = 8080

[demo]
Attributes = Author, Type
MOptions Type = Routine, Software Installation, Problem Fixed, Configuration, Other

and see if it work there? If it works correctly there but not with your config file, please send me your config file and I will try to reproduce the problem.
  2050   Wed Nov 8 08:20:34 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.6.2-1714SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode (was SVN1714 will not run in 'daemon" mode on Solaris8)

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.
  2051   Wed Nov 8 12:55:58 2006 Reply Steve Jonessteve.jones@freescale.comBug reportOther2.6.2-1714SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode (was SVN1714 will not run in 'daemon" mode on Solaris8)

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.

  2052   Wed Nov 8 13:07:31 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.6.2-1714SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode

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.
  2054   Wed Nov 8 15:39:42 2006 Reply deletoillexavier.deletoille@synchrotron-soleil.frBug reportWindows2.6.2-1746Re: checkbox

Stefan Ritt wrote:

deletoille wrote:
I found a small Bug when I create an entry. I activate a checkbox (attachement1) but when I upload a file, the activation disappears (attachement 2). I have to activate again the checkbox.
Is it something I can do?


I tried with V2.6.2-1741 and the problem was not there. It was fixed some time ago, so it should have worked in 1723 as well. Can you try the minimal example coming with the distribution, just by adding one MOptions attribute, like:
[global]
port = 8080

[demo]
Attributes = Author, Type
MOptions Type = Routine, Software Installation, Problem Fixed, Configuration, Other

and see if it work there? If it works correctly there but not with your config file, please send me your config file and I will try to reproduce the problem.



You're right it works
It must be in my programming method
I share you my config file.
Thanks for your help
Attachment 1: Elog_08_11_06.doc
  2109   Fri Jan 12 15:28:46 2007 Warning An Thaithaithan@gmx.deBug reportWindows2.6.3-1776ELOG Crash by many email address
Hello,

when I try to set above 112 email addresses in
"Email All = ..."
the Elog service will crash with the error ntdll.dll or memory addresses x0000000.
This problem does not happen when I reduce the number of email addresses.

Have you had the same problem?
Attachment 1: crash.PNG
crash.PNG
ELOG V3.1.5-3fb85fa6