| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
1943
|
Tue Sep 19 20:28:15 2006 |
 | Stefan Ritt | stefan.ritt@psi.ch | Question | All | 2.6.2-1714 | Re: Re: Why are Preset fields blanked out? |
| Steve Jones wrote: |
Setting the "Type" to "date" causes the blanking to occur.
|
Ok, then don't set the "Type" to "date"  |
|
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
|
|
1945
|
Tue Sep 19 20:38:49 2006 |
| Steve Jones | steve.jones@freescale.com | Question | All | 2.6.2-1714 | Re: Re: Why are Preset fields blanked out? |
| Stefan Ritt wrote: |
| Steve Jones wrote: |
Setting the "Type" to "date" causes the blanking to occur.
|
Ok, then don't set the "Type" to "date" |
| Quote: |
Yuk! Thanks!
|
|
|
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. |
|
1948
|
Fri Sep 22 07:50:39 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | All | 2.6.2-1714 | Re: "Supress Email Notification" checkbox |
| Steve Jones wrote: |
| Steve Jones wrote: | | Is there a way to allow email notification but have the "Suppress Email Notification" checked by default? We had complaints about the enormous amount of email so I turned off email notification for edits/replys, but there are times that I would like to allow email to be sent out -- this would imply allowing email by unchecking the "Suppress" box. |
What I think would be needed is:
Suppress Email on edit = 0|1|2
^
Where a '2' denotes that the "Suppress Email Notification" shows up but *checked* |
Just to a
Suppress default = 1 |
|
1950
|
Fri Sep 22 08:21:39 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | 2.6.2-1714 | Re: Top Text and Bottom Text only show "text" --- no files |
| Steve Jones wrote: | | Stefan, I found the source of the problem. When you moved some files to "logbook_dir" you also told the code to look in "logbook_dir" for top and bottom text files. The documentation indicates that the location dir should be "resource_dir". |
Yepp. I changed the documentation. Note that you can also specify an absolute path, like
/usr/local/elog/top.html
If the file name starts with a "/" (under Unix), the full path is taken instead of looking in the logbook directory. |
|
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.
|
|