If that is your command then it is obvious why no email is send:

you do set "Type=Type", but only for "Type=Problem(s)" and "Category=TDAQ" you would send an email.

Instead of writing "-h host" you should as well define the actual hostname, like "-h midas.psi.ch", likewise for all other parameter.

I didn't realize you required every detail of the command, since the entry is being logged, but here is an example (only the user information is blanked out):

/usr/local/bin/elog -h vmna62s1 -p 8080 -l NA62Logbook -u xxxx xxxx -a Author=Rubin -a Type=Problem\(s\) -a Category=Elog -a Subject="Client Initiated E-mail Notification" "Tests"

From elogd.cfg:

Options Type = Routine{1}, Problem(s){2}, Other{3}
Options Category = Access, Beam, CHANTI, CHOD, Computer/Network, DCS/DSS, Elog, 
GTK, HASC, IRC/SAC, KTAG, LAV, LKr, MUV, NewCHOD, Online Monitor, RICH, Run, Run
 Control, Shift, STRAW, TDAQ

{1} Email Category Elog =
{2} Email Category Elog = Philip.Rubin@cern.ch
{3} Email Category Elog =
 

The TDAQ-category command that is misbehaving is essentially identical:

/usr/local/bin/elog -h vmna62s1 -p 8080 -l NA62Logbook -u xxxx xxxx -a Author="Run Control" -a Type=Problem\(s\) -a Category=TDAQ -a Subject="Board Reload" "KTAG4"

Okay, I can confirm that this does not work. It is likely related to the disclaimer in the ELOG documentation (https://midas.psi.ch/elog/config.html#conditional)

Conditional attributes are usually only used for change items in the entry form.

I guess that the "Email" command never worked with conditional attributes. I use the "Email" command and conditional attributes extensively, but I've never tried before to use "Email" in a condition.

I've tested the functionality with the following minimal configuration for the latest ELOG version 3.1.3-aded4ae :

The following elog command creates the desired entry, but does not send out an email. Creating the identical entry via the web form does initiate the email.

Thank you Phil for pointing out the problem.

Cheers, Andreas

You can allow guests to create entries, but only registered users (Admins) to delete (or edit) entries:

See https://midas.psi.ch/elog/config.html#general for details.

Yes, this is possible by using "Conditional Attributes". Have a look at the ELOG syntax help: https://midas.psi.ch/elog/config.html#conditional

To hide attributes on edit, you can use "Show Attributes Edit =  ..." for the conditions; and you only list the comment reason for the case where the value of the other attribute has the value "reserved".

If you don't get it to work, then just post your logbook config with some comments on what you want to achieve.

Cheers, Andreas

I am having the same issue. If you go to midas.psi.ch/elogs/12345.htm you get the path disclosure issue.

I have to figure out where elog hangs. I guess it must be some kind of endless loop, triggered by some corrupt data in one of the elog entries. Under linux this is fairly simple (just run elogd under the gdb debugger, wait until it hangs, then press ctrl-c and enter "where" to see a full stack dump where elogd is currently executing). Under Windows this is more difficult, since you need Visual C++ from Microsoft to do the debugging. One thing you can do however without VC is to check if the CPU time is consumed to 100% by elogd, indicating an endless loop.

Stefan

I have experience of elog hanging (under linux).  I'll describe my situation, although it may not apply to you.  I still use elog 2.9.2 but I am unaware of this issue ever being resolved although I have mentioned it in the past.  (Possibly because I'm one of the few who has this situation).  I certainly recall other person had this as the problem, and my reply on this forum solved their problem.  The cause is the following:

1.  A thread with a large number of replies - something over 40 I think.

2.  This long thread is deleted from the first entry.  This will crash elog,

3.  Once restarted, the later entries of the deleted thread (which survived the deletion attempt when elog crashed) are accessed.  This will cause elog to go into an endless loop and hang.  Until I learnt better, I had to reboot the computer.  Under linux kill -9 (process) does the job, but kill (process) does not.

The problem lays with the first entry that survived the attempt at deletion.  It has an "In reply to" line in the entry in the yymmdda.log file, referring to an entry that has now been deleted.  Manually editing the yymmdda.log file to remove that line does the trick, and then the surviving entries can be accessed and deleted.

A good work-around is that if you are about to delete a long thread is to delete it in sections, starting at the end.  It is useful to note the entry number or some other way to find it again after the last section is deleted, as of course it will now be back in with the even older entries.  Or have two tabs on your browser accessing the same thread.

If you want to move the long thread to another logbook, to avoid the problem, Copy the thread, and then do the deletion in stages.  Moving a long thread does the same computer crash/computer hang, although the Copying part is done fine, the deletion part is the problem.

You don't have to have a large number of replies to an entry to cause the hang in controlled conditions.  Just edit the yymmdda.log file of a new entry adding in a "In reply to" line referring to an earlier entry number that does not exist is enough to cause the problem when you try and access the thread.

If this is the cause of your issue, the problem is to find the orphan thread that is causing the hang, especially after all this time.  Also, you may have more than one orphan thread.  Even though I am aware of the problem, I do occasionally find orphan threads in my logbooks.  In my case I use the ticketing system, and searching by ticket number will find an orphan thread without hanging the computer, but if you then click on any entry found - hang.

There is a related issue, which I think I have now resolved.  If the entry in the "Reply to" field in the yymmdda.log file does not exist, that is a later entry (not earlier, as above), elog will cause a duplicate entry, always in bold, with entry no 0 to appear in the listings.  This entry is an artifact that appears in the listings, not a real entry in a yymmdda.log file.  Again, finding the rogue entry is the tricky bit.