Re: Append option for elog.exe, posted by Stefan Ritt on Tue Oct 10 11:47:41 2006
|
| Ben Shepherd wrote: | | I think you misunderstand me. I was asking whether it would be possible for the elog command-line client program to have an "append to existing entry" option. |
The elog command-line program has a -e switch to edit existing entries, but you need to know the ID of the entry. |
|
Re: Append option for elog.exe, posted by Ben Shepherd on Tue Oct 10 11:49:15 2006
|
| Stefan Ritt wrote: | | The elog command-line program has a -e switch to edit existing entries, but you need to know the ID of the entry. |
Yes, but if you use -e "text" it replaces the whole entry with "text". So an append option would be really useful... |
Re: 'Inline' button for attachments, posted by Stefan Ritt on Tue Oct 10 16:09:12 2006 
|
| Ben Shepherd wrote: | Hi,
It would be good if when you uploaded an image as an attachment, there was a button next to it that pasted the code [img]elog:1972/1[/img] into the log entry. This way, it would be more easy to have inline images in a log entry. |
Just hit that button:
and it does exactly what you want. |
|
Re: Re: 'Inline' button for attachments, posted by Ben Shepherd on Tue Oct 10 16:15:21 2006
|
| Stefan Ritt wrote: |
| Ben Shepherd wrote: | Hi,
and it does exactly what you want. |
cool! thanks. |
|
Re: SVN1723 (was SVN1714) will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Tue Oct 10 23:29:53 2006
|
| 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.
|
|
|
Re: SVN1723 (was SVN1714) will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Wed Oct 11 00:19:05 2006
|
| 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 ***
|
|
Re: SVN1723 (was SVN1714) will not run in 'daemon" mode on Solaris8, posted by Stefan Ritt on Wed Oct 11 08:18:14 2006
|
| 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. |
|
Re: Elog v2.6.2-1722 appears to have broken "Suppress default [0|1|2|3]" option on Windows XP box, posted by Stefan Ritt on Wed Oct 11 11:47:29 2006
|
| Gregory M. Caughey wrote: | | 2.) However, email notifications will be sent under all circumstances regardless of which parameter selected. |
Thanks for reporting that problem. I just implemented Suppress email on edit and this could have had some side effect. I tried however to reproduce your problem and was not able to. Trying the "minimal" configuration file, the email notifications were suppressed if the check box was checked, or if Suppress default = 3. Can you check if it works with a minimal config file, and if yes, what option in your "full" config file causes this effect? |
|
|
ELOG V3.1.5-3fb85fa6 |
| |