ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
1982
|
Wed Oct 11 16:08:04 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.6.2-1714 | Re: Turn off smileys? |
Yoshio Imai wrote: | Other suggestion: What about going the other way round and making this \?) the smiley and this ?) the usual question in brackets? If there was a special sequence to announce the unusual case (i.e. the smiley), I think less people would complain about having unwanted conversions ... |
I thought also about that, but people who are use to bulletin boards or instant messaging have the common knowledge that a ;) gives a smiley, not a \;). While it would work with the smiley button, which could insert anything, the "other" half of the people who are used to the standard smileys would complain. So I hope that ?-) is acceptable by both sides. |
2021
|
Thu Oct 26 21:54:40 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.2-1714 | SVN1723-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: | There are also strange system calls that differ, and I thought it might be due to the setuid(60001) -nobody- but the the non-daemn mode also sets to nobody and works fine. |
The elogd program opens the port (which might be below 1024 and thus needs privileges), then either become daemon or not, then changes to the user and group specified in elogd.cfg. So this behaviour should be the same on both cases.
Steve Jones wrote: | I just compiled SVN1723 and tried the generic elogd.cfg -- of course *that works!*. Something in my complex config that causes elog to barf when it is attempting to fork the daemon process. |
That's a good starting point. Take your config file, strip one option after the other, and see which is the offending one. This helps us tracking down the problem.
Steve Jones wrote: | I have no idea what "/var/run/syslog_door" is. |
I have not either. But one thing which is different in the daemon mode that all output is redirected to the syslog facility via the function call redirect_to_syslog();. This routine was not written by myself so I don't know 100% what it's doing, just under Linux it works fine. Try to outcomment this function and try again. |
Steve Jones wrote: |
Ok, I've narrowed down the problem to a single attribute. I edited elogd_fancy.cfg as it ships with SVN1723 and found a real bug and an issue:
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;
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 (?).
I reproduced this behavior using the elogd_fancy.cfg that ships.
|
|
2050
|
Wed Nov 8 08:20:34 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.2-1714 | SVN1723-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 |
| Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.2-1714 | SVN1723-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 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.2-1714 | SVN1723-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. |
1882
|
Mon Jul 17 13:44:37 2006 |
| Gerald Ebberink | g.h.p.ebberink@nclr.nl | Comment | Linux | 2.6.2-1706 | Duplicate of a reply should be a reply |
Hello everybody
This weekend I found that if I duplicate a reply it does not become a reply it self.
Is this on purpouse?
I have been through the source a little (not much time for that) and I can not find a reason where the "in reply to" value is dropped.
Could anyone give me an pointer? |
1883
|
Mon Jul 17 13:49:37 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Comment | Linux | 2.6.2-1706 | Re: Duplicate of a reply should be a reply |
Gerald Ebberink wrote: | Hello everybody
This weekend I found that if I duplicate a reply it does not become a reply it self.
Is this on purpouse?
I have been through the source a little (not much time for that) and I can not find a reason where the "in reply to" value is dropped.
Could anyone give me an pointer? |
This is on purpuse. The Duplicate functionality is ment to "clone" an existing entry, to save some typing work if an existing entry contains most of what one wants in a new entry. If one duplicates a reply, it is detached from the original thread, so there is not entry to attach the duplicate to. I guess you want to make a new reply to an existing entry, and then have another existing reply as a template for that, but this is not possible. If I would not drop the "in reply to" value, the duplicate would point to the wrong entry. |
1909
|
Tue Aug 22 11:31:11 2006 |
| Gerald Ebberink | g.h.p.ebberink@nclr.nl | Bug report | Linux | 2.6.2-1706 | reply option in elog client not working |
When I try to make a reply with the following command
elog -v -h hostname -p 80 -l 'logbook wannabe' -u 'guess' 'what' -a 'Phase=During Measuring' -a Author='Gerald Ebberink' -a 'Subject=Octave measurements' -n 1 -f '22-Aug-2006 boxplot hole sizes of panel2SqTop.jpg' -f '22-Aug-2006 boxplot hole area of panel2SqTop.jpg' -f '22-Aug-2006 boxplot POA of panel2SqTop.jpg' -f '22-Aug-2006 boxplot hole sizes of panel2RTop.jpg' -f '22-Aug-2006 boxplot hole area of panel2RTop.jpg' -f '22-Aug-2006 boxplot POA of panel2RTop.jpg' -f '22-Aug-2006 boxplot hole sizes of panel6SqTop.jpg' -f '22-Aug-2006 boxplot hole area of panel6SqTop.jpg' -f '22-Aug-2006 boxplot POA of panel6SqTop.jpg' -f '22-Aug-2006 boxplot comparison of POA.jpg' -r 65 'Automated addition of measurment results (png)'
In verbose mode I found that the main difference is that
with the -r option it wants to go to the following url
Location: http://host/logbook/
and without it goes to
Location http://host/logbook+wannabe/66
my best guess would be that it should also point to logbook+wannabe |