Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 477 of 808  Not logged in ELOG logo
    icon2.gif   Re: propogating messages through logbooks, posted by kenzo Abrahams on Mon Nov 2 07:39:07 2015 elogd.cfgextractTable.py
 
> Hi Kenzo,
> I think it would help me to understand your problem, if you would provide a minimal configuration file with two
> logbooks.
> 
> There is no ELOG internal feature to propagate data from one logbook to another; 
> using a shell script is the only method I know.
> But you could easily put your script into the background: 
> ELOG can handle multiple parallel request, by handling one request after the other.
> 
> Kind Regards, Andreas

Hi Andreas

Im using python to do the scripting. Everything works fine until it comes to submitting the entry to my logbook.
The extractTable.py file is the one running the command to submit to elog.
I see now that im starting a subprocess in my python script (subprocess.call) and thats why its not finishing.
Could you perhaps suggest how I would go about doing this by putting my scripts in the
background? I might have to look at multiprocessing in python as well. The reason im using python is because im
doing alot of file processing as well. I do have to add that this method works perfectly when i just run the python
on its own. As soon as i run it by submiting an elog entrie from the browser it hangs on the subprocess.call method.

Regards, Kenzo
    icon2.gif   Re: propogating messages through logbooks, posted by kenzo Abrahams on Mon Nov 2 08:37:06 2015 
>  
> > Hi Kenzo,
> > I think it would help me to understand your problem, if you would provide a minimal configuration file with two
> > logbooks.
> > 
> > There is no ELOG internal feature to propagate data from one logbook to another; 
> > using a shell script is the only method I know.
> > But you could easily put your script into the background: 
> > ELOG can handle multiple parallel request, by handling one request after the other.
> > 
> > Kind Regards, Andreas
> 
> Hi Andreas
> 
> Im using python to do the scripting. Everything works fine until it comes to submitting the entry to my logbook.
> The extractTable.py file is the one running the command to submit to elog.
> I see now that im starting a subprocess in my python script (subprocess.call) and thats why its not finishing.
> Could you perhaps suggest how I would go about doing this by putting my scripts in the
> background? I might have to look at multiprocessing in python as well. The reason im using python is because im
> doing alot of file processing as well. I do have to add that this method works perfectly when i just run the python
> on its own. As soon as i run it by submiting an elog entrie from the browser it hangs on the subprocess.call method.
> 
> Regards, Kenzo

Hi Andreas

I sorted my problem out, I had to use threading in python such that I can time the submissions to the elog server.
Everything works fine now. Thank you for the assistance.

Regards
Kenzo
icon7.gif   first install comments, posted by Kenneth McFarlane on Sun Jan 24 18:00:11 2010 

I am testing Elog for personal and group use. I am starting with a Windows install on a PC. (I came across Elog when doing a shift on ATLAS at CERN.)

It took me some time to discover how to access a local logbook and create a new one. I suggest adding short sections in a prominent place in the guides:

User guide:

"Accessing a logbook: To access a logbook, point your Web browser at the appropriate URL. The default for a local Elog is http://localhost:8080/logbookname. Logbook files are stored in directory logbookname which is a sub-directory of the logbook root directory, defined by the administrator. See the administrator guide on how to create a new logbook."

Admin guide:

"Creating a logbook: A logbook is created in three steps: 1) The logbook root directory is defined as an option of the elogd start command; 2) A sub-directory, of the logbook root directory, named logbookname is created; and 3) The elogd.cfg file is edited to define the logbook's attributes and options. No files are created in the sub-directory; that is done when entries are made."

Regards,

Ken McF

    icon2.gif   Re: Summary view - Umlauts, posted by Kenneth Andersson on Tue Jan 8 22:30:45 2008 

Uwe wrote:

Stefan Ritt wrote:

Uwe wrote:
    icon2.gif   Re: Summary view - Umlauts, posted by Kenneth Andersson on Tue Jan 8 22:30:45 2008 

Uwe wrote:

Stefan Ritt wrote:

Uwe wrote:
icon6.gif   Completed Swedish translation, posted by Kenneth Andersson on Wed Jan 9 10:43:42 2008 

Hi!

I have completed the Swedish translation and wonder how I can deliver it (if it´s still needed)?

 

//Kenneth

icon4.gif   "Slow script" problem posting/editing from Safari -- browser hangs, times out, posted by Michael Kelsey on Wed Apr 11 18:14:35 2018 

Hello!  The CDMS collaboration is using e-Log as one of it's issue tracking systems.  In the last few months, I have noticed a problem when either creating or editing entries from my usual Safari browser (currently 11.1 on MacOSX 10.13.4):  The [Submit] button triggers a spinning beach ball, with no connection to our e-Log server, and after several minutes, Safari complains the the page had to be reloaded, discarding all of my edits, uploads, whatever.  This used to be occasional, but in the past month it has become routine, such that the only way I can edit or create entries is by launching a different browser entirely (Firefox), just for e-Log editing.

Now, I am also seeing the same problems with Firefox, but at the "occasional" level.  The difference is that Firefox produces some diagnostic information, which is why I'm posting here.  When the browser hangs, after a short while Firefox produces a "Warning: unresponsive script" drop-down box:

Warning: unresponsive script

A script on this page may be busy, or it may have stopped responding.  You can stop the script now, open the script in the debugger, or let the script continue.

Script: http://titus.stanford.edu/cdms…/SuperSim/681?cmd=Edit&steal=1:30

[] Don't ask me again

[Debug script]                       [Stop script]     [Continue]

If I use the [Debug script] button, the call stack shows "onclick 681:1" -> "chkform 681:30", and the line-by-line traceback shows the chkform function:

16   var in_asend = false;
17
18   function chkform()
19   {
20     if (last_key == 13) {
21       var ret = confirm('Really submit this entry?');
22       if (!ret) {
23         last_key = 0;
24         return false;
25       }
26     }
27
28     if (autoSaveTimer != null)
29       clearTimeout(autoSaveTimer);
30     while (in_asend);               <=== This is the stuck line
31     submitted = true;
32     return true;
33   }

I presume that in_asend is supposed to get changed from false to true asynchronously, by some other parallel communication with the server. But that doesn't seem to be happening.

Does this look like an issue with the e-Log distribution? Or is there a configuration issue with our e-Log server which we could improve?

    icon14.gif   Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out, posted by Michael Kelsey on Sun Apr 15 08:03:21 2018 

Thank you for your suggestion, Stefan!  The sysadmin who handles our e-Log server implemented your suggestion earlier today (Saturday).  I have been able to successfully create and modify e-Log entries with Safari since then.  Since the "slow script" issue has been intermittent in the past, I plan to continue testing and monitoring for the next day or so.  Nevertheless, it appears that removing the waiting loop has alleviated my problem.

  -- Mike Kelsey

Followup Sunday 15 Apr (U.S. Pacifiic time):  I think your suggestion has solved my problem.  I've been able to create and modify e-Log entries through our server multiple times over the weekend.  There have been no hangs, timeouts, or lost content.  Thank you very much for your response!

Stefan Ritt wrote:

I'm not 100% sure, but I believe it should work without the 

while (in_asend);

So can you please remove that line (it's in src/elogd.c) and recompile elogd and test it?

Stefan

Michael Hibbard wrote:

I dont' have a solution, but I just wanted to bring more attention to your post. I too am having the same issue with the ELOG system and the Safari browser. I have noticed that ELOG is most stabel and function on the client end from the IE browser. A few weeks ago I also had to switch from using ELOG on the client end from Safari to Firefox.

Michael Kelsey wrote:

Hello!  The CDMS collaboration is using e-Log as one of it's issue tracking systems.  In the last few months, I have noticed a problem when either creating or editing entries from my usual Safari browser (currently 11.1 on MacOSX 10.13.4):  The [Submit] button triggers a spinning beach ball, with no connection to our e-Log server, and after several minutes, Safari complains the the page had to be reloaded, discarding all of my edits, uploads, whatever.  This used to be occasional, but in the past month it has become routine, such that the only way I can edit or create entries is by launching a different browser entirely (Firefox), just for e-Log editing.

Now, I am also seeing the same problems with Firefox, but at the "occasional" level.  The difference is that Firefox produces some diagnostic information, which is why I'm posting here.  When the browser hangs, after a short while Firefox produces a "Warning: unresponsive script" drop-down box:

Warning: unresponsive script

A script on this page may be busy, or it may have stopped responding.  You can stop the script now, open the script in the debugger, or let the script continue.

Script: http://titus.stanford.edu/cdms…/SuperSim/681?cmd=Edit&steal=1:30

[] Don't ask me again

[Debug script]                       [Stop script]     [Continue]

If I use the [Debug script] button, the call stack shows "onclick 681:1" -> "chkform 681:30", and the line-by-line traceback shows the chkform function:

16   var in_asend = false;
17
18   function chkform()
19   {
20     if (last_key == 13) {
21       var ret = confirm('Really submit this entry?');
22       if (!ret) {
23         last_key = 0;
24         return false;
25       }
26     }
27
28     if (autoSaveTimer != null)
29       clearTimeout(autoSaveTimer);
30     while (in_asend);               <=== This is the stuck line
31     submitted = true;
32     return true;
33   }

I presume that in_asend is supposed to get changed from false to true asynchronously, by some other parallel communication with the server. But that doesn't seem to be happening.

Does this look like an issue with the e-Log distribution? Or is there a configuration issue with our e-Log server which we could improve?

 

 

 

ELOG V3.1.5-3fb85fa6