Back Midas Rome Roody Rootana
  Midas DAQ System, Page 113 of 121  Not logged in ELOG logo
ID Date Author Topic Subjectup
  1517   29 Mar 2019 Konstantin OlchanskiBug Reportrmlogger - bk_swap( )
> #5  <signal handler called>
> #6  bk_swap (event=event
> #7  0x000244f0 in root_write (log_chn=0x17ec188, pevent=0x0, evt_size=<optimized out>) at src/mlogger.cxx:3364
> #8  0x0002a8b4 in log_write (log_chn=log_chn
> #9  0x0002b480 in log_odb_dump_json (log_chn=log_chn
> #10 0x0002b5c0 in log_odb_dump (log_chn=log_chn
> #11 0x0002a82c in log_open (log_chn=0x17e9f40, run_number=34, run_number

Ok, here is our bug. It is trying to write the ODB dump through the ROOT writer. Not gonna work.

Simple fix. Set ODB "/Logger/Channels/X/Settings/ODB dump" to "n".

Keep an eye on this for a proper fix
https://bitbucket.org/tmidas/midas/issues/179/mlogger-root-output-crash-from-odb-dump

K.O.
  1527   06 May 2019 Konstantin OlchanskiBug Reportrmlogger - bk_swap( )
> > #5  <signal handler called>
> > #6  bk_swap (event=event
> > #7  0x000244f0 in root_write (log_chn=0x17ec188, pevent=0x0, evt_size=<optimized out>) at src/mlogger.cxx:3364
> > #8  0x0002a8b4 in log_write (log_chn=log_chn
> > #9  0x0002b480 in log_odb_dump_json (log_chn=log_chn
> > #10 0x0002b5c0 in log_odb_dump (log_chn=log_chn
> > #11 0x0002a82c in log_open (log_chn=0x17e9f40, run_number=34, run_number
> 
> Ok, here is our bug. It is trying to write the ODB dump through the ROOT writer. Not gonna work.
> 
> Simple fix. Set ODB "/Logger/Channels/X/Settings/ODB dump" to "n".
> 
> Keep an eye on this for a proper fix
> https://bitbucket.org/tmidas/midas/issues/179/mlogger-root-output-crash-from-odb-dump
> 

partial fix is "in" https://bitbucket.org/tmidas/midas/commits/b9d12098b5d81556a0c7d94b998b51abc4d13bfd

but one still must manually disable writing ODB dumps into this channel.

also double counting of events is not fixed.

this is the most I can do at this moment without setting up at test experiment with a ROOT writer.

K.O.
  1507   28 Mar 2019 Gennaro TortoneBug Fixrmlogger events - double counting
Hi,

I realized that if I use 'rmlogger' to write events in ROOT format,
each event is counted twice;

to fix the problem I commented line 3446 of mlogger.cxx (inside root_write 
function):

 //log_chn->statistics.events_written++;

Regards,
Gennaro
  1512   28 Mar 2019 Konstantin OlchanskiBug Fixrmlogger events - double counting
> I realized that if I use 'rmlogger' to write events in ROOT format,
> each event is counted twice;
> 
> to fix the problem I commented line 3446 of mlogger.cxx (inside root_write 
> function):
> 
>  //log_chn->statistics.events_written++;
> 

I confirm this problem - event counter is incremented by root_write() and by log_write() after calling 
root_write() through the WriterRoot::wr_write().

I will try to fix this for the next release of midas, keep an eye on it here:
https://bitbucket.org/tmidas/midas/issues/177

BTW, I do not think the ROOT writer (and rmlogger) get much use these days, as most experiments we do 
today have data in binary formats that do not fit naturally for storage into ROOT TTree objects. We mostly 
record digitized waveforms and such and they are best stored in binary midas files. The ROOT analyzer 
would read them using the midasio.h classes from the ROOTANA package.

BTW2, for recording MIDAS data, ROOT I/O uses the wrong compression - they compress using gzip, 
which is too slow compared to LZ4 on one side and does not compress as well as BZIP2 on the other side.

K.O.
  Draft   29 Mar 2019 Gennaro TortoneBug Fixrmlogger events - double counting
Hi,

> I confirm this problem - event counter is incremented by root_write() and by log_write() after calling 
> root_write() through the WriterRoot::wr_write().
> 
> I will try to fix this for the next release of midas, keep an eye on it here:
> https://bitbucket.org/tmidas/midas/issues/177

thanks !

> BTW, I do not think the ROOT writer (and rmlogger) get much use these days, as most experiments we do 
> today have data in binary formats that do not fit naturally for storage into ROOT TTree objects. We mostly 
> record digitized waveforms and such and they are best stored in binary midas files. The ROOT analyzer 
> would read them using the midasio.h classes from the ROOTANA package.

yes, I agree with you about this, but to have a "quick and dirty" plot on some ADC channels
can be a very nice "temporary" solution when you are developing your software DAQ...

Regards,
Gennaro

> BTW2, for recording MIDAS data, ROOT I/O uses the wrong compression - they compress using gzip, 
> which is too slow compared to LZ4 on one side and does not compress as well as BZIP2 on the other side.
> 
> K.O.
  1515   29 Mar 2019 Gennaro TortoneBug Fixrmlogger events - double counting
Hi,

> I confirm this problem - event counter is incremented by root_write() and by log_write() after calling 
> root_write() through the WriterRoot::wr_write().
> 
> I will try to fix this for the next release of midas, keep an eye on it here:
> https://bitbucket.org/tmidas/midas/issues/177

thanks !

> BTW, I do not think the ROOT writer (and rmlogger) get much use these days, as most experiments we do 
> today have data in binary formats that do not fit naturally for storage into ROOT TTree objects. We mostly 
> record digitized waveforms and such and they are best stored in binary midas files. The ROOT analyzer 
> would read them using the midasio.h classes from the ROOTANA package.

yes, I agree with you that ROOT files are not suitable to store "first level" data, but this is a very
useful solution when you are developing a software DAQ and you need some (quick) spectra in order
to verify some code...

Regards,
Gennaro
  1518   29 Mar 2019 Konstantin OlchanskiBug Fixrmlogger events - double counting
> 
> > BTW, I do not think the ROOT writer (and rmlogger) get much use these days ...
> 
> yes, I agree with you that ROOT files are not suitable to store "first level" data, but this is a very
> useful solution when you are developing a software DAQ and you need some (quick) spectra in order
> to verify some code...
> 


I confirm that we are keeping the ROOT writer, sometimes it is useful.

Also sorry about all the bugs in that code, it pretty much gets no testing this days, other than by people who try to use it.


K.O.
  1075   23 Jul 2015 Konstantin OlchanskiInforootana lz4 support, mlogger improvements
> A set of improvements to mlogger is in:
> b) test version of LZ4 high speed compression, support for bzip2 and pbzip2

rootana TMidasFile now supports reading .mid.lz4 compressed files via pipe through the "lz4" utility ("yum install lz4", "apt-get install liblz4-tool").

In MIDAS, the lz4 libraries are included with the MIDAS distribution, we are considering the same for ROOTANA.

(Support for reading mid.bz2 files via pipe through the bzip2 utility existed for a very long time).

https://bitbucket.org/tmidas/rootana/commits/e06bb7296a466b4178c7768bbc2470be361b2c72

K.O.
  424   05 Feb 2008 qinzeng pengForumrpc timeout, related to event_size and watch dog? need help
Dear all,

I'm trying to write a simulation code on midas. What I did is just modify the
frontend.c(pp) from experiment samples and made some parameters change on midas.h .

Because my simulation ask for about 4.5MB for each event, so I increase the
MAX_EVENT_SIZE and max_event_size accordingly.

in midas.h :

#define MAX_EVENT_SIZE 0xa00000 //0x400000 /**< maximum event size 4MB*/
#define BANKLIST_MAX 640 //64 /**< max # of banks in event */
#define DEFAULT_RPC_TIMEOUT 60000 //10000
#define WATCHDOG_INTERVAL 5000 //1000
#define DEFAULT_WATCHDOG_TIMEOUT 60000 /**< Watchdog */


in frontend.cpp :

BOOL frontend_call_loop = TRUE;
INT max_event_size = 5 * 1024 * 1024;
INT max_event_size_frag = 2* max_event_size;
INT event_buffer_size = 2 * max_event_size;

EQUIPMENT equipment[] = {

{"WFD_SIMU", /* equipment name */
{1, 0, /* event ID, trigger mask */
"SYSTEM", /* event buffer */
#ifdef USE_INT
EQ_INTERRUPT, /* equipment type */
#else
EQ_POLLED, /* equipment type */
#endif
LAM_SOURCE(0, 0xFFFFFF), /* event source crate 0, all stations */
"MIDAS", /* format */
TRUE, /* enabled */
RO_RUNNING, // | /* read only when running */
// RO_ODB, /* and update ODB */
5000, /* poll for 500ms */
0, /* stop run after this event limit */
0, /* number of sub events */
0, /* don't log history */
"", "", "",},
read_simu_event, /* readout routine */
},
......
}
INT frontend_loop()
{
/* if frontend_call_loop is true, this routine gets called when
the frontend is idle or once between every event */

ss_sleep(100);

return SUCCESS;
}


Compilation OK and running mlogger, odbedit, frontend is OK.
start the run -> no problem ( but there is a long waiting time in frontend if
starting the run. Before the run begins, frontend terminal popping up messages
frequently, say, every 10 seconds. When run starts, frontend terminal hang on
for a couple of minutes before popping up next bunch of messages.)

stop the run -> Problem -> rpc timeout

message from odbedit:

[qzpeng@phy2-dhcp140 simu]$ odbedit -s 10000000
12:54:27 [WFD Simu,INFO] Program WFD Simu on host phy2-dhcp140 started
12:54:37 [Logger,INFO] Program Logger on host phy2-dhcp140 started
[local:simu:S]/>start
Run number [1]: 7
Are the above parameters correct? ([y]/n/q):
Starting run #7
Run #7 started
[local:simu:R]/>stop
[midas.c:9231:rpc_client_call,ERROR] rpc timeout, routine = "rc_transition",
host = "phy2-dhcp140.bu.edu"
Error: Unknown error 504 from client 'WFD Simu' on host phy2-dhcp140.bu.edu
[local:simu:R]/>


runing message from frontend:

[qzpeng@phy2-dhcp140 simu]$ ./frontend
Frontend name : WFD Simu
Event buffer size : 10485760
System max event size : 10485760
User max event size : 5242880
User max frag. size : 10485760
# of events per buffer : 2

Connect to experiment...
OK
Init hardware...
......
  425   06 Feb 2008 Stefan RittForumrpc timeout, related to event_size and watch dog? need help
Most likely you changed the maximal event size in midas.h, but you did not re-compile all programs. The maximal event size goes into the size of the shared memory buffer, so all participating programs have to have the same setting, especially the mserver program. So do the following:

- update to the latest midas version, which is revision 4116
- modify in your midas.h only MAX_EVENT_SIZE. The other settings you modified might have bad side effects. If you increase the RPC timeout, the error will still happen, just later. It comes from the fact that you sent too big events the the server (or the logger), which refuses to take the big events or simply crashes, so the RPC call never returns and after the timeout you get the error.
- recompile all midas programs, don't forget the mserver program
- run the standard demo frontend from the distribution

I tried the above and it just worked fine for me.
  426   06 Feb 2008 qinzeng pengForumrpc timeout, related to event_size and watch dog? need help

Stefan Ritt wrote:
Most likely you changed the maximal event size in midas.h, but you did not re-compile all programs.

Every time I changed midas.h or system header files, I did the re-compile with following procedure:
ipcrm
rm .*.SHM
mcleanup
make clean
make
su
make install

Stefan Ritt wrote:
The maximal event size goes into the size of the shared memory buffer, so all participating programs have to have the same setting, especially the mserver program.

Question here:
How to compile mserver seperately? I think make and make install under midas directory already did the job.


Stefan Ritt wrote:
update to the latest midas version, which is revision 4116

I used latest svn version, so I believe I'm using the latest version 4116.
svn co svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/midas/trunk midas
svn co svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/mxml/trunk mxml

I followed your instructions and did the following:
1)
svn co svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/midas/trunk midas
svn co svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/mxml/trunk mxml
2)
changed two parameters in midas.h
#define MAX_EVENT_SIZE 0xa00000 //0x400000 /**< maximum event size 4MB->10MB*/
#define BANKLIST_MAX 640 //64 /**< max # of banks in event, I need 356 */
3) make
su
make install
I don't know if I need compile mserver seperately.
4) running only two programs:
odbedit -s 10000000
./frontend

And I still got the same problem as before.

[qzpeng@phy2-dhcp140 simu]$ odbedit -s 10000000
[local:simu:S]/>ls
System
Programs
Experiment
Logger
Runinfo
Alarms
[local:simu:S]/>mkdir Equipment
12:44:12 [WFD Simu,INFO] Program WFD Simu on host phy2-dhcp140 started
[local:simu:S]/>start
Run number [1]:
Are the above parameters correct? ([y]/n/q):
Starting run #1
Run #1 started
[local:simu:R]/>stop
[midas.c:9231:rpc_client_call,ERROR] rpc timeout, routine = "rc_transition", host = "phy2-dhcp140.bu.edu"
Error: Unknown error 504 from client 'WFD Simu' on host phy2-dhcp140.bu.edu
[local:simu:R]/>


And I know that the run stopped after a while on frontend, but after the eroor message showed above. If I tried to stop again in odb after a while, it did stopped.
[local:simu:R]/>stop
Run #1 stopped


By the way, thanks for the quick response. I've been working on this for a couple of weeks and I am a newbie.

I also attached my frontend.cpp code and output of make with warning message but comilation completed. Thanks in advance.

In frontend.cpp I only use simulation and don't need any hardware realted issue or function calls but I jsut leave some of them there.
Attachment 1: frontend.cpp
/********************************************************************\

  Name:         frontend.c
  Created by:   Stefan Ritt

  Contents:     Experiment specific readout code (user part) of
                Midas frontend. This example simulates a "trigger
                event" and a "scaler event" which are filled with
                CAMAC or random data. The trigger event is filled
                with two banks (ADC0 and TDC0), the scaler event
                with one bank (SCLR).

  $Id: frontend.c 3384 2006-10-21 04:29:18Z amaudruz $

  Modifed by:   qp Jan/20/2008 for simulation
                Jan 21, add on ROOT
                method: keep old C functions in extern "C" {}
                        define new c++ funcions with ROOT
                read pulse shape from pulseTemplate#.txt
\********************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <time.h>

#include "midas.h"
//#include "mcstd.h"
#include "experim.h"

#include <string.h>

/* ROOT include */
#include "TSystem.h"
#include "TROOT.h"
#include "TFile.h"
#include "TH1.h"
#include "TH2.h"

#include "WFDIndex.h"
WFDIndex *myWFDIndex;

/* for WFD Simu */
const INT n_fills=5000; /*** number of fills per segment from ODB ***/
const INT n_pulses_max=30;
INT n_pulses = 30; /*** number of muons decayed in one fill ***/ 
const int N_WFD=340;
const int N_SHAPE=2400;
const int N_ISLAND=24;
int       N_STEP = N_SHAPE/N_ISLAND;

int debug = 1;    // 0 for no message, 1 for message, 2 for verbose message

typedef struct {
  char  ADC[24];
  DWORD separator;
  DWORD time;
} ISLAND;

static ISLAND island, island_random;

ISLAND gIsland[N_WFD][n_fills*n_pulses_max+1];
INT    gCount[N_WFD];
float  gShape[N_WFD][N_SHAPE];
INT    gPeak[N_WFD];

TFile *f, *fout;
char   histname0[80], histname[80];

/* make frontend functions callable from the C framework */
#ifdef __cplusplus
extern "C" {
#endif

#include "mcstd.h"

/*-- Globals -------------------------------------------------------*/

/* The frontend name (client name) as seen by other MIDAS clients   */
char *frontend_name = "WFD Simu"; //"Sample Frontend";
/* The frontend file name, don't change it */
char *frontend_file_name = __FILE__;

/* frontend_loop is called periodically if this variable is TRUE    */
BOOL frontend_call_loop = TRUE;

/* a frontend status page is displayed with this frequency in ms */
INT display_period = 3000;

/* maximum event size produced by this frontend */
INT max_event_size = 5 * 1024 * 1024;

/* maximum event size for fragmented events (EQ_FRAGMENTED) */
  INT max_event_size_frag = 2* max_event_size;

/* buffer size to hold events */
  INT event_buffer_size = 2 * max_event_size;

/* number of channels */
#define N_ADC  4
#define N_TDC  4
#define N_SCLR 4

  /* CAMAC crate and slots */
#define CRATE      0
#define SLOT_IO   23
#define SLOT_ADC   1
#define SLOT_TDC   2
#define SLOT_SCLR  3

/*-- Function declarations -----------------------------------------*/

INT frontend_init();
INT frontend_exit();
INT begin_of_run(INT run_number, char *error);
INT end_of_run(INT run_number, char *error);
INT pause_run(INT run_number, char *error);
INT resume_run(INT run_number, char *error);
INT frontend_loop();

INT read_simu_event(char *pevent, INT off);
INT read_scaler_event(char *pevent, INT off);
void register_cnaf_callback(int debug);

INT poll_event(INT source, INT count, BOOL test);
INT interrupt_configure(INT cmd, INT source, POINTER_T adr);

/*-- Equipment list ------------------------------------------------*/

#undef USE_INT

EQUIPMENT equipment[] = {

   {"WFD_SIMU",              /* equipment name */
    {1, 0,                   /* event ID, trigger mask */
     "SYSTEM",               /* event buffer */
#ifdef USE_INT
     EQ_INTERRUPT,           /* equipment type */
#else
     EQ_POLLED,              /* equipment type */
#endif
     LAM_SOURCE(0, 0xFFFFFF),        /* event source crate 0, all stations */
     "MIDAS",                /* format */
     TRUE,                   /* enabled */
     RO_RUNNING, // |            /* read only when running */
     //     RO_ODB,                 /* and update ODB */
     5000,                     /* poll for 500ms */
     0,                      /* stop run after this event limit */
     0,                      /* number of sub events */
     0,                      /* don't log history */
     "", "", "",},
    read_simu_event,         /* readout routine */
    },

   {"Scaler",                /* equipment name */
    {2, 0,                   /* event ID, trigger mask */
     "SYSTEM",               /* event buffer */
     EQ_PERIODIC | EQ_MANUAL_TRIG,   /* equipment type */
     0,                      /* event source */
     "MIDAS",                /* format */
     TRUE,                   /* enabled */
     RO_RUNNING | RO_TRANSITIONS |   /* read when running and on transitions */
     RO_ODB,                 /* and update ODB */
     10000,                  /* read every 10 sec */
     0,                      /* stop run after this event limit */
     0,                      /* number of sub events */
     0,                      /* log history */
     "", "", "",},
    read_scaler_event,       /* readout routine */
   },

   {""}
};

#ifdef __cplusplus
}
#endif

INT wfd_get_shape(void);
INT wfd_get_hist(void);
double wfd_get_random(int sn, int choice);

/********************************************************************\
              Callback routines for system transitions

  These routines are called whenever a system transition like start/
  stop of a run occurs. The routines are called on the following
  occations:

  frontend_init:  When the frontend program is started. This routine
                  should initialize the hardware.

  frontend_exit:  When the frontend program is shut down. Can be used
                  to releas any locked resources like memory, commu-
                  nications ports etc.

  begin_of_run:   When a new run is started. Clear scalers, open
                  rungates, etc.

  end_of_run:     Called on a request to stop a run. Can send
                  end-of-run event and close run gates.

  pause_run:      When a run is paused. Should disable trigger events.

  resume_run:     When a run is resumed. Should enable trigger events.
\********************************************************************/

/*-- Frontend Init -------------------------------------------------*/

INT frontend_init()
{
  /* hardware initialization */

  cam_init();
  cam_crate_clear(CRATE);
  cam_crate_zinit(CRATE);

  /* enable LAM in IO unit */
  camc(CRATE, SLOT_IO, 0, 26);

  /* enable LAM in crate controller */
  cam_lam_enable(CRATE, SLOT_IO);

  /* reset external LAM Flip-Flop */
  camo(CRATE, SLOT_IO, 1, 16, 0xFF);
  camo(CRATE, SLOT_IO, 1, 16, 0);

  /* register CNAF functionality from cnaf_callback.c with debug output */
  register_cnaf_callback(1);

  /* print message and return FE_ERR_HW if frontend should not be started */

  wfd_get_hist();

  wfd_get_shape();

  myWFDIndex = new WFDIndex();

   return SUCCESS;
}

/*-- Frontend Exit -------------------------------------------------*/

INT frontend_exit()
{
   return SUCCESS;
}

/*-- Begin of Run --------------------------------------------------*/

INT begin_of_run(INT run_number, char *error)
{
   /* put here clear scalers etc. */
  island.ADC[0] = 5;
  island.ADC[1] = 6;
  island.ADC[2] = 7;
  island.ADC[3] = 5;
  island.ADC[4] = 7;
  island.ADC[5] = 20;
  island.ADC[6] = 30;
  island.ADC[7] = 50;
  island.ADC[8] = 90;
  island.ADC[9] = 120;
  island.ADC[10] = 150;
  island.ADC[11] = 200;
  island.ADC[12] = 165;
  island.ADC[13] = 130;
  island.ADC[14] = 110;
  island.ADC[15] = 90;
  island.ADC[16] = 30;
  island.ADC[17] = 10;
  island.ADC[18] = 7;
  island.ADC[19] = 4;
  island.ADC[20] = 6;
  island.ADC[21] = 5;
  island.ADC[22] = 3;
  island.ADC[23] = 6;
  //island.ADC[24] = 7;
  //island.ADC[25] = 6;
  //island.ADC[26] = 6;
  //island.ADC[27] = 7;   
  //island.ADC[28] = 5;
  //island.ADC[29] = 5;
  //island.ADC[30] = 6;
  //island.ADC[31] = 5;

  island.separator = 0x0;
  island.time = 0x00010001;

  //  wfd_get_hist();

   return SUCCESS;
}

INT wfd_get_hist(void)
{
  gROOT->Reset();

  char filename0[] = "IslandParameters";
  char runname[] = "57140-57170"; 
... 338 more lines ...
Attachment 2: make-output.txt
[qzpeng@phy2-dhcp140 midas]$ make
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/midas.o src/midas.c
src/midas.c: In function °∆bm_open_buffer°«:
src/midas.c:4020: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/midas.c: In function °∆rpc_server_connect°«:
src/midas.c:8259: warning: pointer targets in passing argument 3 of °∆getsockname°« differ in signedness
src/midas.c:8261: warning: pointer targets in passing argument 3 of °∆getsockname°« differ in signedness
src/midas.c:8263: warning: pointer targets in passing argument 3 of °∆getsockname°« differ in signedness
src/midas.c:8376: warning: pointer targets in passing argument 3 of °∆accept°« differ in signedness
src/midas.c:8378: warning: pointer targets in passing argument 3 of °∆accept°« differ in signedness
src/midas.c:8380: warning: pointer targets in passing argument 3 of °∆accept°« differ in signedness
src/midas.c: In function °∆rpc_register_server°«:
src/midas.c:10533: warning: pointer targets in passing argument 3 of °∆getsockname°« differ in signedness
src/midas.c: In function °∆rpc_server_accept°«:
src/midas.c:11230: warning: pointer targets in passing argument 3 of °∆accept°« differ in signedness
src/midas.c:11239: warning: pointer targets in passing argument 3 of °∆getpeername°« differ in signedness
src/midas.c: In function °∆rpc_client_accept°«:
src/midas.c:11493: warning: pointer targets in passing argument 3 of °∆accept°« differ in signedness
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/system.o src/system.c
src/system.c: In function °∆ss_suspend_init_ipc°«:
src/system.c:2948: warning: pointer targets in passing argument 3 of °∆getsockname°« differ in signedness
src/system.c: In function °∆ss_suspend°«:
src/system.c:3416: warning: pointer targets in passing argument 6 of °∆recvfrom°« differ in signedness
src/system.c:3443: warning: pointer targets in passing argument 6 of °∆recvfrom°« differ in signedness
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mrpc.o src/mrpc.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/odb.o src/odb.c
src/odb.c: In function °∆db_open_database°«:
src/odb.c:891: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/odb.c: In function °∆db_lock_database°«:
src/odb.c:1441: warning: dereferencing type-punned pointer will break strict-aliasing rules
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/ybos.o src/ybos.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/ftplib.o src/ftplib.c
src/ftplib.c: In function °∆ftp_data°«:
src/ftplib.c:288: warning: pointer targets in passing argument 3 of °∆getsockname°« differ in signedness
src/ftplib.c:310: warning: pointer targets in passing argument 3 of °∆accept°« differ in signedness
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mxml.o ../mxml/mxml.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/cnaf_callback.o src/cnaf_callback.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/history.o src/history.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/alarm.o src/alarm.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/elog.o src/elog.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/strlcpy.o ../mxml/strlcpy.c
rm -f linux/lib/libmidas.a
ar -crv linux/lib/libmidas.a linux/lib/midas.o linux/lib/system.o linux/lib/mrpc.o linux/lib/odb.o linux/lib/ybos.o linux/lib/ftplib.o linux/lib/mxml.o linux/lib/cnaf_callback.o linux/lib/history.o linux/lib/alarm.o linux/lib/elog.o linux/lib/strlcpy.o
a - linux/lib/midas.o
a - linux/lib/system.o
a - linux/lib/mrpc.o
a - linux/lib/odb.o
a - linux/lib/ybos.o
a - linux/lib/ftplib.o
a - linux/lib/mxml.o
a - linux/lib/cnaf_callback.o
a - linux/lib/history.o
a - linux/lib/alarm.o
a - linux/lib/elog.o
a - linux/lib/strlcpy.o
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mana.o src/mana.c
g++ -DUSE_ROOT -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -pthread -m32 -I/usr/root/include -o linux/lib/rmana.o src/mana.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mfe.o src/mfe.c
src/mfe.c: In function °∆scheduler°«:
src/mfe.c:1869: warning: pointer targets in passing argument 5 of °∆db_get_value°« differ in signedness
src/mfe.c:2042: warning: pointer targets in passing argument 5 of °∆db_get_value°« differ in signedness
src/mfe.c:2051: warning: pointer targets in passing argument 5 of °∆db_get_value°« differ in signedness
g++ -Dextname -DMANA_LITE -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/fal.o src/fal.c
src/fal.c:106: warning: non-local variable °∆<anonymous struct> out_info°« uses anonymous type
src/fal.c: In function °∆INT midas_log_open(LOG_CHN*, INT)°«:
src/fal.c:1194: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/fal.c: In function °∆INT dump_log_open(LOG_CHN*, INT)°«:
src/fal.c:1582: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/fal.c: In function °∆INT ascii_log_open(LOG_CHN*, INT)°«:
src/fal.c:1803: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/fal.c: At global scope:
src/fal.c:3064: warning: non-local variable °∆<anonymous struct> eb°« uses anonymous type
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mserver src/mserver.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mhttpd src/mhttpd.c src/mgd.c linux/lib/libmidas.a -lutil -lpthread -lz -lm
g++ -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mlogger src/mlogger.c linux/lib/libmidas.a -L/usr/root/lib -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -pthread -lm -ldl -rdynamic -Wl,-rpath,/usr/root/lib  -lutil -lpthread -lz
src/mlogger.c: In function °∆INT midas_log_open(LOG_CHN*, INT)°«:
src/mlogger.c:1094: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/mlogger.c: In function °∆INT dump_log_open(LOG_CHN*, INT)°«:
src/mlogger.c:1530: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/mlogger.c: In function °∆INT ascii_log_open(LOG_CHN*, INT)°«:
src/mlogger.c:1750: warning: dereferencing type-punned pointer will break strict-aliasing rules
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/odbedit src/odbedit.c src/cmdedit.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mtape utils/mtape.c linux/lib/libmidas.a -lutil -lpthread -lz
utils/mtape.c: In function °∆tape_dir°«:
utils/mtape.c:84: warning: dereferencing type-punned pointer will break strict-aliasing rules
utils/mtape.c:87: warning: dereferencing type-punned pointer will break strict-aliasing rules
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mhist utils/mhist.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mstat utils/mstat.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mcnaf utils/mcnaf.c drivers/camac/camacrpc.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mdump utils/mdump.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/lazylogger src/lazylogger.c linux/lib/libmidas.a -lutil -lpthread -lz
g++ -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mhdump utils/mhdump.cxx
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mchart utils/mchart.c linux/lib/libmidas.a -lutil -lpthread -lz
cp -f utils/stripchart.tcl linux/bin/. 
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/webpaw utils/webpaw.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/odbhist utils/odbhist.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/melog utils/melog.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mlxspeaker utils/mlxspeaker.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB   -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/dio utils/dio.c
[qzpeng@phy2-dhcp140 midas]$ 
  427   06 Feb 2008 Stefan RittForumrpc timeout, related to event_size and watch dog? need help
First of all, I would appreciate if you do not post your entry ten times. Each time you edit it, you produce an email notification going to everybody, so people might get annoyed to receive too many emails from you. Think what you want to write and then post once.

Second, I told you to use the frontend from the distribution, but you used your own code. Since I successfully ran the demo frontend with the large event size, the origin of your problem must be "in between". So start with the demo frontend, try it, then modify its buffer size in frontend.c, then try again. When I told to to recompile midas, I meant you should also recompile your front-end each time you change midas.h. The mserver is automatically recompiled when you recompile and install midas (just check the /usr/local/bin/mserver date and time to confirm that it got updated during your last "make install"). Then add things from your specific front-end program step by step to see at which step the problem occurs the first time. This gives you some hint where the real cause lies.
  1143   24 Nov 2015 Robert PattieForumrpc_client_dispatch error
I'm trying to set up an experiment with 2 frontends for the first time.  When I
start the remote frontend I get the following errors:

first time (odd attempt):

[MCS_Frontend_203,ERROR] [midas.c:9678:rpc_server_connect,ERROR] mserver
subprocess could not be started (check path)
[MCS_Frontend_203,ERROR] [mfe.c:2696:mainFE,ERROR] Cannot connect to experiment
'Default' on host 'ucntau-daq.lanl.gov', status 503

second time (even attempt):

MCS6A_frontend: src/midas.c:9085: rpc_client_dispatch: Assertion `n ==
sizeof(NET_COMMAND_HEADER) + 4 * sizeof(INT)' failed.

On the local host I'm running : mlogger, a frontend, an analzer, mhttp, and
mserver.  I followed the instructions for adding the remote computer to the
RPC_ALLOWED list and I do see that the remote frontend was able to edit the
local odb equipment list.  At present I'm not running an event builder I just
wanted to get the frontends connected to start.  Do I need to have the mserver
running on both computers?  Any suggestions on where to start troubleshooting this?

Thanks 
  1144   25 Nov 2015 Konstantin OlchanskiForumrpc_client_dispatch error
Not clear on what you are doing, so here is the brief description:

- you have two machines - say "midas" and "frontend"
- you run mttpd, mlogger, etc on "midas"
- you want to run some frontend on "frontend"

Do this:
- on "midas", open a new terminal, run "mserver -p 7071"
- on "frontend", open a new terminal, run "odbedit -h midas:7071"

If you did follow all the online instruction correctly, at this point, your odbedit on "frontend" would have 
connected and all commands would work same as if run locally on "midas".

If I understand you correctly, you got this far.

Next do this:
- on "frontend", open a new terminal, run "your_frontend.exe -h midas:7071"

If all is good, the frontend would start, would connect to midas, you would see
it in odbedit "scl" and on the midas status page and you would be able to stop
it from the midas "programs" page. (this last bit is important).

I guess this is where things go wrong and you do not get anything working.

Do this:
a) cut and paste all the output from the terminal window where you are running the mserver (including the 
command you used to start the mserver)
b) cut and paste all the output from the terminal window where you are starting the frontemd (again, 
including the command you used to start the frontend)
c) cut  and paste the contents of midas.log (in the experiment directory) from the time you started the 
mserver until the very end.

Paste all this as reply to this message or email it to me at olchansk@triumf.ca

With this additional information we should be able to get you going (and hopefully improve the 
documentation so the next person does not run into the same problem - whatever the problem turns out to 
be).

K.O.

> I'm trying to set up an experiment with 2 frontends for the first time.  When I
> start the remote frontend I get the following errors:
> 
> first time (odd attempt):
> 
> [MCS_Frontend_203,ERROR] [midas.c:9678:rpc_server_connect,ERROR] mserver
> subprocess could not be started (check path)
> [MCS_Frontend_203,ERROR] [mfe.c:2696:mainFE,ERROR] Cannot connect to experiment
> 'Default' on host 'ucntau-daq.lanl.gov', status 503
> 
> second time (even attempt):
> 
> MCS6A_frontend: src/midas.c:9085: rpc_client_dispatch: Assertion `n ==
> sizeof(NET_COMMAND_HEADER) + 4 * sizeof(INT)' failed.
> 
> On the local host I'm running : mlogger, a frontend, an analzer, mhttp, and
> mserver.  I followed the instructions for adding the remote computer to the
> RPC_ALLOWED list and I do see that the remote frontend was able to edit the
> local odb equipment list.  At present I'm not running an event builder I just
> wanted to get the frontends connected to start.  Do I need to have the mserver
> running on both computers?  Any suggestions on where to start troubleshooting this?
> 
> Thanks 
  1273   18 Apr 2017 Andreas SuterBug Reportrun 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. 
  1288   02 May 2017 Konstantin OlchanskiBug Reportrun start/stop oddity
I should really get around to fix this junk error message:

> 07:13:32.335 2017/04/19 [Logger,ERROR] [midas.c:14079:rpc_server_receive,ERROR]
> rpc check ok, abort canceled

What happens is this. For each run transition, cm_transition does RPC calls
to each client telling them to transition. So even if you run only on localhost, there is still
tcp connections being created and broken to do these RPCs. These connections are
typically created and left open, but when you stop odbedit, it's connections would
be closed/broken. Now in the midas rpc code there is confusion between the main rpc
connection for remote clients and temporary rpc connections for run transitions. This
confusion is the cause of these junk error messages - first the code thinks that the main rpc
connection is closed it it should commit suicide (abort), then it find that it was
just an rpc connection and there is no need to die.

https://bitbucket.org/tmidas/midas/issues/44/junk-messages-about-rpc-check-ok-abort

>
> - Enable non-localhost RPC -> y
> - Disable RPC hosts check  -> y
> 

this is unsafe:

if you only run on localhost, "enable non-localhost rpc" should be "n" and midas will no listen to any 
outside connections (except for mhttpd, of course).

if you have remote clients, enable non-localhost rpc and enter their hostnames to the access control list.

"disable rpc hosts check" is for the case where you do not know the hostnames of your remote clients, 
for example when they come from dynamic ip addresses on a wifi network.

In this case you tell midas to accept connections from everybody everywhere in the world
and hopefully you have a firewall somewhere to prevent the evil hackers from actually connecting.
I hope this is not your situation.

K.O.
  969   27 Feb 2014 Andreas SuterSuggestionrunlog is "ugly"
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.
  •   970   27 Feb 2014 Konstantin OlchanskiSuggestionrunlog is "ugly"
    > 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.
      973   28 Feb 2014 Andreas SuterSuggestionrunlog is "ugly"
    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.
    Attachment 1: mhttpd.cxx.diff
    diff --git a/src/mhttpd.cxx b/src/mhttpd.cxx
    index 7437897..3940b96 100755
    --- a/src/mhttpd.cxx
    +++ b/src/mhttpd.cxx
    @@ -3445,7 +3445,7 @@ void show_rawfile(const char *path)
        rsprintf("</table>");
     
        //main table:
    -   rsprintf("<table class=\"dialogTable\">");
    +   rsprintf("<table class=\"runlogTable\">");
        /*---- menu buttons ----*/
        rsprintf("<tr><td colspan=2>\n");
        rsprintf("<input type=submit name=cmd value=\"ELog\">\n");
    
    Attachment 2: mhttpd.css.diff
    diff --git a/resources/mhttpd.css b/resources/mhttpd.css
    index 71c73a4..066cfe6 100644
    --- a/resources/mhttpd.css
    +++ b/resources/mhttpd.css
    @@ -286,7 +286,7 @@ div.wrapper{
         margin: 0 auto -3em;
     }
     
    -.historyConfigTable, .dialogTable, .messageBox, .genericTable, .sequencerTable{
    +.historyConfigTable, .runlogTable, .dialogTable, .messageBox, .genericTable, .sequencerTable{
     	border-radius: 12px;
     	border: 2px solid #00B26B;
     	background-color: #EEEEEE;
    @@ -304,6 +304,22 @@ table.sequencerTable td table{
     	margin: 0px;
     }
     
    +table.genericTable tr:nth-child(even){
    +	background: #EEEEEE;
    +}
    +table.genericTable tr:nth-child(odd){
    +	background: #FAFAFA;
    +}
    +
    +table.runlogTable td{
    +        border:none;
    +        text-align: left;
    +        font-family: monospace;
    +}
    +
    +table.runlogTable pre{
    +        line-height: 125%;
    +}
     
     table.dialogTable td{
     	border:none;
    
      974   28 Feb 2014 Stefan RittSuggestionrunlog is "ugly"
     > If I am not mistaken, the mhttpd.css is hard coded (path/name) into the mhttpd.
    
    I agree that this should be removed, Unfortunately I'm away right now, so I will fix it next week. Also will put in 
    Andreas' diffs.
    
    /Stefan
    ELOG V3.1.4-2e1708b5