 18 Dec 2003, Stefan Ritt, , Poll about default indent style
|
Hi Paul,
I agree with you that a nesting level of more than 4-5 is a bad thing, but I
|
|
01 Jan 2004, Konstantin Olchanski, , Poll about default indent style
|
> I don't feel a strong need of giving up a "-i2"...
I am comfortable with the current MIDAS styling convention and I would rather not
|
|
06 Jan 2004, Stefan Ritt, , Poll about default indent style
|
Ok, taking all comments so far into account, I conclude adopting the ROOT
coding style would be best for us. So I put
|
 24 Jul 2015, Konstantin Olchanski, Info, Plans for improving midas network security
|
There is a number of problems with network security in midas. (as separate from web/http/https security).
1) too many network sockets are unnecessarily bound to the external network interface instead of localhost (UDP ports are already bound to localhost on |
|
24 Jul 2015, Konstantin Olchanski, Info, Plans for improving midas network security
|
There is a number of problems with network security in midas. (as separate from
web/http/https security).
|
|
28 Jul 2015, Konstantin Olchanski, Info, Plans for improving midas network security
|
New git branch "feature/rpcsecurity" implements these security features:
- all UDP ports are bound to the localhost interface - connections from outside are not possible
|
|
15 Nov 2003, Konstantin Olchanski, , Phantom "open records"
|
Sometimes (maybe after a client uncleanly exits?), I see phantom "open
records", for example:
[local:twist:Running]Gas>sor
|
|
16 Nov 2003, Stefan Ritt, , Phantom
|
I have seen the same behaviour and it annoys me, too. What I did in the past
is a "cleanup" in ODBEdit which removes these open records. I have soem code
in cm_watchdog(), which should take care of that. If a client is dead, it
|
|
20 Nov 2003, Stefan Ritt, , Phantom
|
I tried to reproduce the problem, but without success. So in case this happens
again, one should debug the code im cm_watchdog() next to the line
|
|
11 Apr 2013, Thorsten Lux, Forum, Persistent ipcrm error
|
Hello,
I have a problem with our DAQ which is based on Midas. Until now, for about 3 years, it worked quite well but since I tried to restart data taking after |
|
11 Apr 2013, Konstantin Olchanski, Forum, Persistent ipcrm error
|
> [system.c:308:ss_shm_open,ERROR] Shared memory segment with key 0x4d008002 already exists,
please remove it manually: ipcrm -M 0x4d008002
> [midas.c:1950:cm_connect_experiment1,ERROR] cannot open database
|
|
11 Apr 2013, Stefan Ritt, Forum, Persistent ipcrm error
|
[quote="Thorsten Lux"]In addition now I cannot start anymore the mlogger from the web interface but only manually. However, I can stop it from the web interface.[/quote]
At least that one can be fixed easily. Each program has a certain command with which one can start it. This has to be put into the ODB under /Programs/<program>. |
|
12 Apr 2013, Thorsten Lux, Forum, Persistent ipcrm error
|
[quote="Stefan Ritt"][quote="Thorsten Lux"]In addition now I cannot start
anymore the mlogger from the web interface but only manually. However, I can
stop it from the web interface.[/quote]
|
|
12 Apr 2013, Stefan Ritt, Forum, Persistent ipcrm error
|
> Hi Stefan,
>
|
|
12 Apr 2013, Thorsten Lux, Forum, Persistent ipcrm error
|
>
> > Hi Stefan,
> >
|
|
12 Apr 2013, Thorsten Lux, Forum, Persistent ipcrm error
|
Hi,
it seems that I solved the problem in a quite brutal way.
|
|
12 Apr 2013, Stefan Ritt, Forum, Persistent ipcrm error
|
> [odb.c:6038:db_paste,ERROR] found string exceeding MAX_STRING_LENGTH
Ok, so here is what probably happened. Some user program wrote a long string into the ODB and somehow corrupted it. This corruption persists as long as |
|
20 Jan 2005, Konstantin Olchanski, Bug Report, Persistency problem with h1_book() & co
|
The current h1_book() macros (and the previous example analyzer code) have an
odd persistency problem: for example, the user wants to change some histogram
limits, edits the h1_book() calls, rebuilds and restarts the analyzer, starts a
|
|
21 Jan 2005, John M O'Donnell, Bug Report, Persistency problem with h1_book() & co
|
> The current h1_book() macros (and the previous example analyzer code) have an
> odd persistency problem: for example, the user wants to change some histogram
> limits, edits the h1_book() calls, rebuilds and restarts the analyzer, starts a
|
|
21 Jan 2005, Stefan Ritt, Bug Report, Persistency problem with h1_book() & co
|
> I can't get onto cvs@midas.psi.ch right now
> (cvs update
> cvs@midas.psi.ch's password:
|