| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
1944
|
Tue Sep 19 20:37:59 2006 |
 | Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.2-1714 | Shell execution generating error | When started as root *but not running as a daemon* shell execution results in the following errors that are sent to Standard Error:
Cannot restore original GID/UID.
Cannot remove pidfile "/var/run/cr-elogd.pid"
; Permission denied
Cannot restore original GID/UID.
Cannot remove pidfile "/var/run/cr-elogd.pid"
; Permission denied
|
|
1946
|
Fri Sep 22 07:42:57 2006 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.2-1714 | Re: Shell execution generating error |
| Steve Jones wrote: | When started as root *but not running as a daemon* shell execution results in the following errors that are sent to Standard Error:
Cannot restore original GID/UID.
Cannot remove pidfile "/var/run/cr-elogd.pid"
; Permission denied
Cannot restore original GID/UID.
Cannot remove pidfile "/var/run/cr-elogd.pid"
; Permission denied
|
The "/var/run/elogd.pid" file is created from elogd to indicate under which PID it is running. If you run elogd once under root, this file then belongs to root. If you afterwards run it under a user account, it cannot delete or change the file belonging to root. In that case, just delete that file manually. |
|
1947
|
Fri Sep 22 07:47:58 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.2-1714 | Re: SVN1714 will not run in 'daemon" mode on Solaris8 |
| 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. |
|
1953
|
Fri Sep 22 19:31:15 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.2-1714 | Re: Shell execution generating error |
| Stefan Ritt wrote: |
| Steve Jones wrote: | When started as root *but not running as a daemon* shell execution results in the following errors that are sent to Standard Error:
Cannot restore original GID/UID.
Cannot remove pidfile "/var/run/cr-elogd.pid"
; Permission denied
Cannot restore original GID/UID.
Cannot remove pidfile "/var/run/cr-elogd.pid"
; Permission denied
|
The "/var/run/elogd.pid" file is created from elogd to indicate under which PID it is running. If you run elogd once under root, this file then belongs to root. If you afterwards run it under a user account, it cannot delete or change the file belonging to root. In that case, just delete that file manually. |
| Quote: |
When a process starts via the normal startup process it is started as root then the process changes to run as nobody -- so the pid file will always be owned by root. Yes? Then, shell commands wil not be able to deal with the pid file, right? Why would the shell exec want to deal with the PID file anyway?
Just curious. As long as this does not pose a problem then I will nto worry about it.
|
|
|
1954
|
Fri Sep 22 19:32:45 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.2-1714 | Re: 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, what this tells me is I need to get TRUSS to follow the fork - which I think I can do. The behavior, however, is that elog never goes into daemon mode after that fork.
More info to follow.
|
|
|
1956
|
Fri Sep 22 22:12:18 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.2-1714 | Re: 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 |
| 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 ***
|
|
|
ELOG V3.1.5-3fb85fa6 | |