| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
1960
|
Fri Sep 29 18:35:09 2006 |
 | marta flood | marta33911@aol.com | Question | | | Entering information |
I am not sure how to get to the page I need to log my clinical time for school and I have no idea how I got here
Thanks,
Marta |
|
1959
|
Mon Sep 25 21:09:58 2006 |
 | Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.6.2 | Re: Entry Submission Help |
| kcmin wrote: | | 1. When an entry is submitted is it possible to have it return to the submit page instead of a summary of the entry. In the ELog.cfg syntax on the site it mentions something about this. However It says something about a file being present in the resource directory. I am not sure what to do here. |
You can hand-write a HTML file which gets displayed after submission, but that's probably not what you want. Unfortunately there is no option to go back to the submit page, so you have to click New again. If you want to enter a bulk of data, you can also do a CSV import. Maybe that's easier for you. Just write a comma-separated-value file, and import it via "CSV Import".
| kcmin wrote: | | 2. When you submit an entry is it possible for the fields to stay set to the value that was selected on submission of the last entry. You would need to still be able to change them though. |
The Duplicate command was made for that. Just select an entry which is close to your new one (might be the last one entered), and click Duplicate. This gets you to what you want. |
|
1958
|
Mon Sep 25 18:23:54 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.6.1 | Re: Invalid addresses block email notifications |
| Dimitrios Tsirigkas wrote: | Hi Stefan,
We have had problems with some users who subscribe for elog notifications using fake email addresses. When this happens, e-mail notifications stop working for all users and I have to find out which is the problematic email address and fix it myself. Is this a known problem? Is there a fix in a version newer than 2.6.1?
Thanks,
Dimitris |
Hi Dimitris,
in fact I have the same problem here with the forum. So far I did not find a clever solution, but I have some thought on how to minimize it:
- Do the self registration by sending a key to the registered email address. Only by using that key the account can be activated. This way at least on ensures a proper email address initially. There are however ways to temporaryly generate email accounts, which kind of bypasses this system. Furthermore, if an email address becomes invalid because the domain is switched off, this does not help.
- Email at least an error notification to the admin in case of failure.
You would say "why not removing the invalid email address"? Well that's kind of hard, since I send the email notification to all recipients in one email. Therefor I cannot figure out which is the offending email address. If I would send the emails separately to everyone, this can easily take minutes, which in turn would block the email server for that time. A solution would be a multithreaded server, which in fact is planned, but will not come so soon. If you come up with another clever solution please let me know. |
|
1957
|
Mon Sep 25 15:30:48 2006 |
 | Dimitrios Tsirigkas | dimitrios.tsirigkas@cern.ch | Question | Linux | 2.6.1 | Invalid addresses block email notifications |
Hi Stefan,
We have had problems with some users who subscribe for elog notifications using fake email addresses. When this happens, e-mail notifications stop working for all users and I have to find out which is the problematic email address and fix it myself. Is this a known problem? Is there a fix in a version newer than 2.6.1?
Thanks,
Dimitris |
|
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. |
|
|
1955
|
Fri Sep 22 19:42:21 2006 |
| Steve Jones | steve.jones@freescale.com | Question | All | 2.6.2-1714 | Re: "Supress Email Notification" checkbox |
| Stefan Ritt wrote: |
| 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 |
| Quote: |
Not quite what I am looking for. What I need is:
"New" Logs
- Always send an email -- do not provide an option to check the box.
-- use Suppress Default = 2
"Edits and Replys"
- Provide the option to send an email, but by default the "suppress" box is checked
-- need Suppress Email on edit = 2
|
|
|
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.
|
|
|
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.
|
|