ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
1975
|
Tue Oct 10 23:27:41 2006 |
| Steve Jones | steve.jones@freescale.com | Question | All | 2.6.2-1714 | Re: "Supress Email Notification" checkbox |
Stefan Ritt wrote: | Suppress email on edit has been implemented in the current SVN revision just similar to the Suppress default flag having possible values of 0, 1, 2 and 3. |
Works like a champ! Thanks |
1976
|
Tue Oct 10 23:29:53 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.2-1714 | Re: SVN1723 (was SVN1714) will not run in 'daemon" mode on Solaris8 |
Steve Jones wrote: |
Stefan Ritt wrote: |
Steve Jones wrote: | 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" |
The "one where it errors out" does not look like an error. It does the "fork()" at the end and the main thread ends, that's how it's supposed to be. |
Quote: | Ok, I got it. I've attached the TRUSS output where we follow the fork. It appears that elogd cannot open any of the specified files then gives up. What was throwing me is no error output, even to STDERR. When I run the same but without the -D flag the files are opened fine.
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. |
|
Quote: |
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. To me the TRUSS output indicates that elog can't seem to find any logfile to work on -- very bizarre.
|
|
1977
|
Wed Oct 11 00:19:05 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.2-1714 | Re: SVN1723 (was SVN1714) will not run in 'daemon" mode on Solaris8 |
Steve Jones wrote: |
Steve Jones wrote: |
Stefan Ritt wrote: |
Steve Jones wrote: | 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" |
The "one where it errors out" does not look like an error. It does the "fork()" at the end and the main thread ends, that's how it's supposed to be. |
Quote: | Ok, I got it. I've attached the TRUSS output where we follow the fork. It appears that elogd cannot open any of the specified files then gives up. What was throwing me is no error output, even to STDERR. When I run the same but without the -D flag the files are opened fine.
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. |
|
Quote: |
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. To me the TRUSS output indicates that elog can't seem to find any logfile to work on -- very bizarre.
Stefan, you might find this interesting. I went ahead and removed all references to pre-existing logbook directories and restarted with TRUSS tracing the program. Elogd managed to go into daemon mode but the minute it received a request it generated a segmentation fault. Notice that even though elog could not open the logging directory it went ahead and went into polling mode. I have no idea what "/var/run/syslog_door" is. Working on isolating.
4190: seteuid(60001) = 0
4190: stat("/sysadm/www/elog/cr-elogd.cfg", 0xFFBC9558) = 0
4190: stat("/usr/lib/locale/english/english.so.2", 0xFFBC85C0) Err#2 ENOENT
4190: stat("/sysadm/www/elog/resources/eloglang.", 0xFFBC9348) Err#2 ENOENT
4190: listen(3, 5, 1) = 0
4190: fstat(4, 0xFFBC9318) = 0
4190: time() = 1160518513
4190: getpid() = 4190 [1]
4190: putmsg(4, 0xFFBC89D0, 0xFFBC89C4, 0) = 0
4190: open("/var/run/syslog_door", O_RDONLY) = 7
4190: door_info(7, 0xFFBC8908) = 0
4190: getpid() = 4190 [1]
4190: door_call(7, 0xFFBC88F0) = 0
4190: close(7) = 0
4190: open("crlogbooks/logs/elogaccess.log", O_RDWR|O_APPEND|O_CREAT, 0644) Err#2 ENOENT
4190: poll(0xFFBC7640, 1, 1000) = 0
4190: poll(0xFFBC7640, 1, 1000) (sleeping...)
4190: poll(0xFFBC7640, 1, 1000) = 0
4190: poll(0xFFBC7640, 1, 1000) = 0
4190: poll(0xFFBC7640, 1, 1000) = 1
4190: accept(3, 0xFFBEF300, 0xFFBC9830, 1) = 7
4190: time() = 1160518516
4190: poll(0xFFBC7640, 1, 6000) = 1
4190: recv(7, " G E T / H T T P / 1".., 100000, 0) = 610
4190: Incurred fault #6, FLTBOUNDS %pc = 0x0001EA1C
4190: siginfo: SIGSEGV SEGV_MAPERR addr=0xFF3EFE30
4190: Received signal #11, SIGSEGV [default]
4190: siginfo: SIGSEGV SEGV_MAPERR addr=0xFF3EFE30
4190: *** process killed ***
|
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.
|
|
2023
|
Fri Oct 27 19:11:32 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | All | 2.6.2-1723 | Interesting behavior with $shell | eLog does not do math so I am trying to leverage the $SHELL function to perform the math. I am using GAWK to perform the math -- I started trying to use CONDITIONAL ATTRIBUTES to assign numeric values to attributes but with loading up the ATTRIBUTES with all of the options brings elog to its knees in terms of performance -- the parsing of attributes is simply too string intensive.
So, I embedded the numeric score in the OPTIONS of the ATTRIBUTE and leveraged the text processing prowess of GAWK:
Options WhoIsEffected = 1:...Single User, 5:...Project, 10:...Department, 50:...Site
Options ServiceOutage = 1:...0-1 Minutes, 2:...10 Minutes, 10:...20 Minutes, 30:...30 Minutes, 100:...gt60
Then pass the following command to GAWK:
Preset TotalScore = $shell(gawk 'BEGIN{split(\"$WhoIsEffected:$ServiceOutage\",scores,\":\");print scores[1]+scores[3]}' )
The interesting result is this works - the proper summation is returned but apparently elog parsing also returns everything after the first ')' as something that also needs to be returned. So the resulting contents of TotalScore is 2;print scores[1]+scores[3]}' ) assuming one chose the first option of both attributes (the output pasted here are real results).
Before getting to this point I tried using the GAWK internal variable of $0 - but this did not work because apparently $0 in elog is defined as the OS shell!
Stefan, is it possible for you to try creating a logbook on the elog demo site that shows people how to perform math and in the process discover what the $SHELL function is doing? |
2024
|
Sun Oct 29 16:04:05 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | All | 2.6.2-1723 | Re: Interesting behavior with $shell |
Steve Jones wrote: | eLog does not do math so I am trying to leverage the $SHELL function to perform the math. I am using GAWK to perform the math -- I started trying to use CONDITIONAL ATTRIBUTES to assign numeric values to attributes but with loading up the ATTRIBUTES with all of the options brings elog to its knees in terms of performance -- the parsing of attributes is simply too string intensive.
So, I embedded the numeric score in the OPTIONS of the ATTRIBUTE and leveraged the text processing prowess of GAWK:
Options WhoIsEffected = 1:...Single User, 5:...Project, 10:...Department, 50:...Site
Options ServiceOutage = 1:...0-1 Minutes, 2:...10 Minutes, 10:...20 Minutes, 30:...30 Minutes, 100:...gt60
Then pass the following command to GAWK:
Preset TotalScore = $shell(gawk 'BEGIN{split(\"$WhoIsEffected:$ServiceOutage\",scores,\":\");print scores[1]+scores[3]}' )
The interesting result is this works - the proper summation is returned but apparently elog parsing also returns everything after the first ')' as something that also needs to be returned. So the resulting contents of TotalScore is 2;print scores[1]+scores[3]}' ) assuming one chose the first option of both attributes (the output pasted here are real results).
Before getting to this point I tried using the GAWK internal variable of $0 - but this did not work because apparently $0 in elog is defined as the OS shell!
Stefan, is it possible for you to try creating a logbook on the elog demo site that shows people how to perform math and in the process discover what the $SHELL function is doing? |
Steve Jones wrote: |
So, in order to quickly get around the problem I did the following:
Preset TotalScore = $shell(echo \"$WhoIsEffected:$ServiceOutage\" | gawk -f <gawkscript>' )
This works since all of the script logic is contained in an external script but removes the logic from the elog config, so if anything changes one has to remember to change the script (which is in a comment).
|
|
2027
|
Tue Oct 31 22:07:06 2006 |
| Steve Jones | steve.jones@freescale.com | Question | Linux | 2.6.2-1739 | Re: calling a shell in the Options tag |
Alexandre Lindote wrote: | Hi,
is it possible to run a shell script in an "Options" tag, as it is with the "Preset", "Subst", and so on?
I need to have something like this:
Options Update of = $shell(/home/alex/zeplin3/elog/z3elog-mirror/documents/ext_docs.sh MinGen)
the script returns a line with comma separated values...
Thanks
Alex |
Steve Jones wrote: |
Alex, have you tried it? Novel idea!
|
|
2028
|
Tue Oct 31 22:10:11 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | Windows | V2.6.2-172 | Re: checkbox |
deletoille wrote: | Hello,
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?
Thanks in advance,
Xavier Deletoille |
Steve Jones wrote: |
Xavier, your version number does not indicate the full SVN (it is cutoff at '172') but your screenshot indicates 'SVN1723'. This is an identified problem and looks to be fixed in SVN1740. I have verified with the checkbox "Suppress Email Notification" -- it likely effects all checkboxes.
|
|
|
ELOG V3.1.5-2eba886 | |