Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 644 of 808  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Show attachments  Show only new entries    6457 Entries 
Goto page Previous  1, 2, 3 ... 643, 644, 645 ... 806, 807, 808   Next  
ID Date Icon Author Author Email Categorydown OS ELOG Version Subject
  1956   Fri Sep 22 22:12:18 2006 Reply Steve Jonessteve.jones@freescale.comBug reportOther2.6.2-1714Re: SVN1714 will not run in 'daemon" mode on Solaris8

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.
  1976   Tue Oct 10 23:29:53 2006 Reply Steve Jonessteve.jones@freescale.comBug reportOther2.6.2-1714Re: 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 Reply Steve Jonessteve.jones@freescale.comBug reportOther2.6.2-1714Re: 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 ***
  1978   Wed Oct 11 08:18:14 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.6.2-1714Re: SVN1723 (was SVN1714) will not run in 'daemon" mode on Solaris8

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.
  1979   Wed Oct 11 11:37:03 2006 Disagree Gregory M. Caugheycaugheygm@aol.comBug reportWindows2.6.2-1722Elog v2.6.2-1722 appears to have broken "Suppress default [0|1|2|3]" option on Windows XP box
Hi Stefan!

Been running Elog-2.6.2-1714 successfully for a while and yesterday decided to download and experiment with the latest Elog-2.6.2-1722 build. I want to report a possible bug involving the "Suppress default" option when running build 2.6.2-1722 on a Windows XP laptop. I installed 2.6.2-1722 into a development folder and copied my current production 'elogd.cfg' file and other custom files to the development folder. Test postings produced the following results:

1.) The "Suppress default [0|1|2|3]" option causes the [] Suppress Email notification to display or not display as expected.

2.) However, email notifications will be sent under all circumstances regardless of which parameter selected.

3.) Downgrading to Elog-2.6.2-1714 produces the expected behavior.

I am running Windows XP with all current upgrades and security patches and Internet Explorer 7 - version: 7.0.5700.6

Regards, Greg
  1980   Wed Oct 11 11:47:29 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportWindows2.6.2-1722Re: Elog v2.6.2-1722 appears to have broken "Suppress default [0|1|2|3]" option on Windows XP box

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?
  1983   Wed Oct 11 19:37:10 2006 Idea Gregory M. Caugheycaugheygm@aol.comBug reportWindows2.6.2-1722Re: Elog v2.6.2-1722 appears to have broken "Suppress default [0|1|2|3]" option on Windows XP box

Stefan Ritt wrote:

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?

OK, you're absolutely correct. When I run Elog-2.6.2-1722 with a minimal 'elogd.cfg' the "Suppress default [0|1|2|3]" flag does appear to behave as expected. Taking your advice I went through my local 'elogd.cfg' evaluating items to see where the problem starts and I found a problem. In my local config file I use conditional attributes to modify the "category" and "type" fields (in the posting form) and here is what I'm finding wrong. For this example I have set "Suppress default = 3" and the following actions take place:

1.) Select "New" to begin a post and the form displays correctly with NO "[] Suppress Email notification" checkbox showing.

2.) When selecting "Category" an choosing an appropriate menu item the form is then redrawn and now there is a problem, the "[] Suppress Email notification" checkbox is displaying. The checkbox does work correctly but the behavior I'm expecting is for no checkbox to display during the composition of this posting. Am I misunderstanding the behavior of the "Suppress default = 3" flag?

3.) Each of the other flag parameters appear to work as expected as used in the above example.

I have attached screenshots that demonstrate this behavior as well as a snippet of the 'elogd.cfg' file.

Hope this helps a little...

Thanks, Greg
  1987   Fri Oct 13 16:59:13 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportWindows2.6.2-1722Re: Elog v2.6.2-1722 appears to have broken "Suppress default [0|1|2|3]" option on Windows XP box

Gregory M. Caughey wrote:
Hope this helps a little...


Yepp it helped. I could reproduce your problem and fix it. Can you try elog262-4.exe (Revision 1729)?
Goto page Previous  1, 2, 3 ... 643, 644, 645 ... 806, 807, 808   Next  
ELOG V3.1.5-3fb85fa6