Back Midas Rome Roody Rootana
  Midas DAQ System, Page 3 of 136  Not logged in ELOG logo
Entry  17 Jan 2011, Andreas Suter, Bug Report, Problems with midas history SVN 4936 
I have the following problems after updating to midas SVN 4936: the history 
system (web-page via mhttpd) seems to stop working. I checked the history files 
themself and they are indeed written, except that the events ID's are not the 
same anymore (I mean the ones defined under /Equipment/XXX/Common/Event ID), 
rather the mlogger seems to choose an ID by itself.
Currently the only way to get things working again was to recompile midas with 
adding -DOLD_HISTORY to the CFLAGS which is troublesome since it is likely to be 
forgotton with the next SVN update. When looking into the SVN I have the 
impression there is something going on concerning the history system, however
I couldn't find any documentation.
What is the best practice for the future, in order not to run into any problems 
but still being able to look at the old history (also from within the web-page 
via mhttpd)?
Entry  11 Feb 2014, Andreas Suter, Bug Report, mhttpd, etc. arrayIndex_b.jpegmultiDriverSet.jpegmultiDriverSet_labels.jpegheader1.jpeg
I found a couple of bugs in the current mhttpd, midas version: "93fa5ed"

This concerns all browser I checked (firefox, chrome, internet explorer, opera)

1) When trying to change a value of a frontend using a multi class driver (we
have a lot of them), the field for changing appears, but I cannot get it set!
Neither via the two set buttons (why 2?) nor via return.


It also would be nice, if the css could be changed such that input/output for
multi-driver would be better separated; something along as suggested in


2) If I changing a value (generic/hv class driver), the index of the array
remains when chaning a value until the next update of the page


3) We are using a web-password. In the current version the password is plain visible when entering.

4) I just copied the header as described here: https://midas.triumf.ca/elog/Midas/908, but I get another result:

It looks like as a wrong cookie is filtered?
Entry  27 Feb 2014, Andreas Suter, Suggestion, runlog is "ugly" runlog-default.pngmhttp_css_1.pngmhttp_css_2.pngrunlog-proposal.png
I have a couple of questions and suggestions concerning the "new" CSS style of the mhttpd, especially related to the runlog

  1. If I am not mistaken, the mhttpd.css is hard coded (path/name) into the mhttpd. Wouldn't it be beneficial to have ODB entries where to get is from? This way people could change the look and feel more freely.
  2. Especially the look and feel of the runlog is unsatisfactorily from my point of view. See . The old style was much more readable. I could recover the old style look and feel by slightly changing the mhttpd.cxx where I changed in show_rawfile(const char*) "dialogTable" to "runlogTable" in the table class. This way I could tinker around with the mhttpd.css by adding the following stuff there:
    • adding .runlogTable in line 289 :
    • adding some style information for the runlogTable :
This way the "old" runlog look and feel recovered : , which I think is much more readable.
  • If possible, I would love to have alternating background colors between the runs for readability reasons, but I am not sure how easy it would be to add something like this.
    I not much experience with HTML/CSS yet, though a concrete implementation might be different.
  •     Reply  28 Feb 2014, Andreas Suter, Suggestion, runlog is "ugly" mhttpd.cxx.diffmhttpd.css.diff
    Understand me right, I mostly like the new style, except the runlog as reported.
    Attached you will find the diff's you were asking for. But as pointed out, I
    haven't worked so far on CSS and hence this should be checked!!
    
    I understand that the mhttpd.js needs to be the default one, however, mhttpd.css
    might be left to the end-user to adopt to their specific needs. I shortly
    checked in the mhttpd demon. It checks for the resources path in the ODB. If it
    also would check for a CSS name, mhttpd.css could be changed/adopted by the
    end-users without breaking things (at least it would then be their one business).
    
    > > If I am not mistaken, the mhttpd.css is hard coded (path/name) into the mhttpd.
    > 
    > mhttpd.css is served from $MIDASSYS/resources/mhttpd.css. The actual path is
    reported on the mhttpd 
    > "help" page.
    > 
    > (I think the internal mhttpd.css and mhttpd.js should be removed as no longer
    useful - nothing will work 
    > right if the real mhttpd.js and mhttpd.css cannot be served).
    > 
    > > Especially the look and feel of the runlog is unsatisfactorily from my point
    of view.
    > 
    > persons in charge of implementing the CSS stuff failed to convert quite a few
    pages, for example, the elog 
    > and the history editor pages were left completely broken. (mostly fixed now).
    > 
    > so thank you for reporting the runlog breakage, I hope Stefan & co can fix it
    quickly. (I cannot do - I have 
    > have no runlog pages on any of my test experiments).
    > 
    > > the old style was much more readable.
    > 
    > I think the new style is not too bad, except for a few visual artefacts here
    and there, the general comment 
    > that CSS is too complicated and hard to debug and the fact that over-subtle
    colouring yields inconsistent 
    > visuals between different monitors and ambient lighting conditions. (persons
    who select the colours always 
    > respond that "but to me, it looks just fine on my laptop", making it hard to
    resolve any issues).
    > 
    > > I could recover the old style look and feel by slightly changing the mhttpd.cxx
    > 
    > If you post the patches that fix it for you, I can commit them to midas. (git
    diff | mail olchansk@triumf.ca).
    > 
    > K.O.
    Entry  11 Mar 2014, Andreas Suter, Forum, mlogger problem 
    I stumbled over a problem which I cannot pin point and would appreciate suggestions.

    I set up an experiment, and all of a sudden I noticed the following behaviour.

    I can start any number of frontends without any problems as long as mlogger is NOT running.
    I can also start mlogger without any problems. However, as soon as I started the mlogger, I cannot start anything else any more (including odbedit). I get the following assertion:
    16:07:06 [Logger,INFO] Program Logger on host lem00 started
    [local:nemu:S]/>q
    [nemu@lem00 2014]$ odbedit -e nemu
    odbedit: src/odb.c:753: db_update_open_record: Assertion `xkey->notify_count == pkey->notify_count' failed.
    Aborted
    
    This is even happening if I stop all frontends, start only the mlogger and afterwards try to start odbedit.

    I tried to see if this is a generic feature on a test experiment, but there I cannot reproduce it. It seems that there is either something wrong with the ODB, something wrong with hotlinks, ..., I don't know.

    I would appreciated suggestions how pin point the issue.
        Reply  11 Mar 2014, Andreas Suter, Forum, mlogger problem 

    Stefan Ritt wrote:

    Andreas Suter wrote:
    I stumbled over a problem which I cannot pin point and would appreciate suggestions.

    I set up an experiment, and all of a sudden I noticed the following behaviour.

    I can start any number of frontends without any problems as long as mlogger is NOT running.
    I can also start mlogger without any problems. However, as soon as I started the mlogger, I cannot start anything else any more (including odbedit). I get the following assertion:
    16:07:06 [Logger,INFO] Program Logger on host lem00 started
    [local:nemu:S]/>q
    [nemu@lem00 2014]$ odbedit -e nemu
    odbedit: src/odb.c:753: db_update_open_record: Assertion `xkey->notify_count == pkey->notify_count' failed.
    Aborted
    
    This is even happening if I stop all frontends, start only the mlogger and afterwards try to start odbedit.

    I tried to see if this is a generic feature on a test experiment, but there I cannot reproduce it. It seems that there is either something wrong with the ODB, something wrong with hotlinks, ..., I don't know.

    I would appreciated suggestions how pin point the issue.


    K.O. put that in: https://bitbucket.org/tmidas/midas/commits/9d7b7c83b275a2bd3c846c4f265ff7f5d53f3426

    He should have a look at it.

    Have you tried to rebuild your ODB from scratch? (Save in XML, then delete .ODB.SHM, then load again form XML)?

    /Stefan

    Yes, I could recover the ODB by falling back to a previous dump. Still, I would like to know what is the exact meaning of the above assertion. It might help to understand what are the likely cause which results in the assertion.

    /Andreas
    Entry  12 Mar 2014, Andreas Suter, Info, Windows support droped? 
    In the old SVN midas world it was typically such that the Windows dll's and
    exe's were ready to be used when checking out. I am not so sure this is the case
    for the current version, since when I use the packed dll's  and exe's (e.g.
    odbedit.exe) I get the warning that this is running midas 2.0.0 but the current
    version (on the linux server) is 2.1.
    
    What does this mean?
    
    1) A little bug in the packed windows part, but up-to-date dll's and exe's?
    2) The dll's and exe's are not bundled any more to up-to-date version?
    
    If 2) is the case, I would like to get a hint how to build midas under Windows
    (Windows 7), since we still have some few Windows clients.  
    Entry  13 May 2015, Andreas Suter, Forum, Check if Client is running from Javascript 
    Is there currently an easy way to check from javascript if a midas client is
    running? I mean an equivalent to cm_exist.

    Sometimes this would be very useful in custom pages.
        Reply  14 May 2015, Andreas Suter, Forum, Check if Client is running from Javascript 
    Thanks a lot! This helps for now.

    Thomas Lindner wrote:

    Andreas Suter wrote:
    Is there currently an easy way to check from javascript if a midas client is
    running? I mean an equivalent to cm_exist.

    Sometimes this would be very useful in custom pages.


    It is not as clean as what you asked, but I have in the past written javascript like this to check if a program is running

    var req = new Array();
    req[0]= "Programs/towerfe3_00/First failed";
    var result = ODBMGet(req);
    if(result[0] == 0){
    // then program is running
    }
    Entry  23 Aug 2016, Andreas Suter, Forum, Alarm/Warning 
    Midas has a nice alarm system. I am wondering whether it is easily possible to
    get the Alarm/Warning banner also on top of custom pages?!
    Entry  14 Mar 2017, Andreas Suter, Bug Report, mhttpd - /Experiment/Menu Buttons - git-sha a350e8db11 
    I think there sneaked in a little bug in the mhttpd: when starting an experiment
    from scratch and starting the mhttpd, the Menu Buttons are missing and,
    correctly, I get periodic error messages. I expected that the default ODB entry
    for the Menu Buttons is create if it doesn't exist. As far as I see this happens
    now since the default creation of the 'Menu Buttons' is now tag as an obsolete
    feature. In case this is not a bug but a feature, it should documented.
    Entry  05 Apr 2017, Andreas Suter, Suggestion, nicer header?! 
    We use the customHeader to display some useful information. Currently I do not
    like its style. What about to make it more alike the footer?
    
    I just changed in resources/mhttpd.css
    
    diff --git a/resources/mhttpd.css b/resources/mhttpd.css
    index fb0070d..f3264c8 100644
    --- a/resources/mhttpd.css
    +++ b/resources/mhttpd.css
    @@ -280,6 +280,15 @@ table.headerTable td{
            border: none;
     }
     
    +div.headerDiv{
    +       background-color: #6F6F6F;
    +       text-align: center;
    +       padding:1em;
    +       color:#EEEEEE;
    +       border-bottom:1px solid #000000;
    +       height:3em;
    +}
    +
     div.footerDiv{
            background-color: #808080;
            text-align: center;
    
    and
    
    diff --git a/resources/mhttpd.js b/resources/mhttpd.js
    index de8bc6c..972c261 100644
    --- a/resources/mhttpd.js
    +++ b/resources/mhttpd.js
    @@ -172,7 +172,7 @@ function mhttpd_goto_page(page) {
     
     function mhttpd_navigation_bar(current_page, path)
     {
    -   document.write("<div id=\"customHeader\">\n");
    +   document.write("<div class=\"headerDiv\" id=\"customHeader\">\n");
        document.write("</div>\n");
     
        document.write("<div class=\"mnavcss\">\n");
    
    What do you think?
    Entry  05 Apr 2017, Andreas Suter, Bug Report, Equipment Expand doesn't work anymore 
    I'd liked very much the possibility to hide away Equipment on the main page. It
    is also nice to have the '+' to get it quickly back when needed. However, this
    seems not to work anymore (git c9d9d604803). Is this a feature or something went
    wrong?
        Reply  10 Apr 2017, Andreas Suter, Bug Report, Equipment Expand doesn't work anymore 
    > > I'd liked very much the possibility to hide away Equipment on the main page. It
    > > is also nice to have the '+' to get it quickly back when needed. However, this
    > > seems not to work anymore (git c9d9d604803). Is this a feature or something went
    > > wrong?
    > 
    > The expansion of the equipment list is handled by a Cookie ("expeq" being 1 or 0). When Konstantin 
    > implemented the mongoose server instead of the internal mhttp server, he neglected to evaluate 
    > this cookie. I fixed this now (also renamed the cookie to "midas_expeq") in the current development 
    > branch. Please check if it's working.
    > 
    > Stefan
    
    Tested it on two machines and expansion is back and working! Thanks a lot!
    
    Andreas
    Entry  13 Apr 2017, Andreas Suter, Bug Report, stop form odbedit broken 
    when I try to stop a run from odbedit I get a core dump.
    
    [ODBEdit1,INFO] Run #31 stopped odbedit: src/system.c:1223: ss_shm_flush:
    Assertion `size == mmap_size[handle]' failed. Aborted (core dumped)
    
    midas commit 53af92a5d0...
    
    -----
    
    I checked what happens if I try to stop a run via the mhttpd web-page: this
    works! So what is different?
    
    -----
    
    I placed a issue (# 47) on bitbucket as well.
    
    What is the preferred channel to report potential bugs (elog / bitbucket issues)? 
        Reply  13 Apr 2017, Andreas Suter, Bug Report, stop form odbedit broken 
    > when I try to stop a run from odbedit I get a core dump.
    > 
    > [ODBEdit1,INFO] Run #31 stopped odbedit: src/system.c:1223: ss_shm_flush:
    > Assertion `size == mmap_size[handle]' failed. Aborted (core dumped)
    > 
    > midas commit 53af92a5d0...
    > 
    > -----
    > 
    > I checked what happens if I try to stop a run via the mhttpd web-page: this
    > works! So what is different?
    > 
    > -----
    > 
    > I placed a issue (# 47) on bitbucket as well.
    > 
    > What is the preferred channel to report potential bugs (elog / bitbucket issues)? 
    
    I think I found the problem. Some ODB String values which are **automatically**
    generated:
    
    CSS File = STRING : [1024] mhttpd.css
    Sqlite dir = STRING : [1024]
    History dir = STRING : [1024]
    Sound = STRING : [1000] alarm.mp3
    
    are exceeding the MAX_STRING_LENGTH 256 (defined in msystem.h)
    
    It looks as if this screws up quite a bit of the system! When deleting .ODB.SHM and
    afterwards try to reload the ODB via a dump I previously made with odbedit, the
    following is happening:
    
    1) I get the error message that some strings are too long (exceeding
    MAX_STRING_LENGTH). Unfortunately the underlying routine doesn't tell which ODB
    variables this is.
    
    2) After this reload, essentially nothing is working anymore. Any client I tried to
    start just crashed.
    
    Since it seems that the string length of MAX_STRING_LENGTH is very crucial I would
    suggest that db_create_record (or whatever routine is dealing with it) checks for
    STRING variables and ensures that they cannot exceed MAX_STRING_LENGTH.
    
    When I shortened in my dump the above variables to MAX_STRING_LENGTH, regenerated the
    ODB, also the 'stop' Problem in odbedit is gone.
    Entry  18 Apr 2017, Andreas Suter, Bug Report, run start/stop oddity  
    I stumbled over an oddity which I would like to understand better. Here the
    boundaries:
    - Enable non-localhost RPC -> y
    - Disable RPC hosts check  -> y
    
    1) I am starting a run from ODBedit (start now -v):
    
    07:13:11.272 2017/04/19 [ODBEdit,INFO] Run #26 started
    
    07:13:25.516 2017/04/19 [Logger,LOG] File '/data/max/dlog/lem17_0026.root'
    CRC32C checksum: 0x05ca4e7e, 1523383 bytes
    
    On this little test experiment there is not much running, but it already shows
    the effect I wanted to understand.
    
    2) I am stopping the run from ODBedit (stop -v):
    
    07:13:25.519 2017/04/19 [ODBEdit,INFO] Run #26 stopped
    
    So, everything looks perfectly fine up to this point.
    
    3) Now the 'strange' thing happens. To any point in time after this, I will stop
    ODBEdit which results in the following messages:
    
    07:13:32.335 2017/04/19 [ODBEdit,INFO] Program ODBEdit on host pc7962 stopped
    
    07:13:32.335 2017/04/19 [Logger,ERROR] [midas.c:14079:rpc_server_receive,ERROR]
    rpc check ok, abort canceled
    
    This I do NOT understand! It looks as if the Logger (or any other client which
    gets the run state transition) thinks that some Client (here ODBEdit) has a
    broken connection. At least this is how I understand the comment in midas.c /
    rpc_server_receive(). Is something broken in the de-registration from the RPC
    server? By the way, all clients where running on the localhost, i.e. no remote
    connection used here.
    
    All this only happens if a run transition took place.
    
    Unfortunately I do not understand the system well enough to suggest any fix to
    this :-( and hence would appreciate any help. 
    Entry  09 May 2017, Andreas Suter, Bug Report, mhttpd / history / export data 
    A handy feature of the history of the mhttpd is to export the data. However, this 
    seems to be broken. It currently only works if the run marker flag is activated by 
    fails otherwise.
    Entry  10 Jan 2018, Andreas Suter, Bug Report, mhttpd - custom page - RHEL/Fedora system.c.diff
    Description of the problem (starting with 61be7a1):
    
    When starting a new experiment, creating a fresh ODB and than adding the 
    directory '/Custom', the mhttpd runs into a problem on RHEL/Fedora, but not on 
    Ubuntu and macOS. When trying to open the ODB from within whatever browser I get 
    the following error message in the midas message queque:
    
    [mhttpd,ERROR] [mhttpd.cxx:563:rread,ERROR] Cannot read file '/root', read of 
    4096 returned -1, errno 21 (Is a directory)
    
    and in the browser I get a popup which tries to save a file called 'root'.
    
    I track this down to the following: in mhttpd, interprete (line 18046) it is 
    check if a custom page file exists (ss_file_exist) and if yes, it tries to 'load' 
    it. Now, at this stage the variable dec_path contains '/root'.
    
    Here now what goes wrong: ss_file_exist tries to open the given path, and if a 
    valid file descriptor is returned it assumes the file exists. This is not 
    perfectly correct since it also will get a valid file descriptor is path is an 
    accessible directory!
    
    Now for whatever reason, on RHEL/Fedora '/root' will return a valid file 
    descriptor, but not on macOS and Ubuntu. Others I haven't tested. A possible fix 
    would be to check explicitly if path is a directory and if yes return 0 in 
    ss_file_exist (see attached diff).
    
    Perhaps there is cleaner way to deal with this issue?! 
        Reply  15 Jan 2018, Andreas Suter, Bug Report, mhttpd - custom page - RHEL/Fedora 
    > > In any case, IMO, mhttpd has no business serving the contents of /root,
    > > or serving any files outside of the mhttpd user $HOME directory. (but also
    > > should not serve files from ~user/.ssh, or any other "secret" files, good
    > > luck making a complete axhuastive list of all secret files that should not be
    > > served).
    > 
    > I fully agree with Konstantin. mhttpd should only serve files under certain directories. One is the 
    > midas/resources directory, another is the one defined in the ODB under /Custom/Path. I plan to modify 
    > mhttpd to only serve these files (and also prevent tricks like putting "../../../" into the URL). This will then 
    > also fix Andreas' problem.
    > 
    > Stefan
    
    Yes, I think this is a good idea as well. But just to make sure that you get the problem: it's not the custom page call by itself! If you currently type e.g. <midas-server>/root it will open the ODB html-page.
    ELOG V3.1.4-2e1708b5