Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Linux Mxssvr service down

Hi there,

 

Here is my problem :

 

Background : NiDAQmx 8.0 on RHEL5 (even if I know that this distrib is not officially supported). Our application is developped in C language. Our board are 6254 and 6259 M devices

The aim of our application is to acquired data in a continuous way (our application is based on ContAcq-IntClk sample).

Sometimes, we stop and restart the application (for example to take in account a new configuration), but it's aimed to run nonstop..

 

I have noticed that each 20days / 30days our application fail to start (after stopping to change the configuration for example).

If I run nilsdev it return nothing.

 

After investigation I see that the mxssvr service stopped runnning.

If I restart it (/etc/init.d/mxssvr start), everythings goes well : I can restart my application and nilsdev return correct informations.

 

Someone has an idea on the reason why mxssvr stopped ?  

 

One more information : I had no network modification type static => dynamic (I saw a post about it). 

Also I have modified my /etc/cron.daily/tmpwatch in order to not delete /tmp/nipal to avoid kernel panic (I saw a KB about it)

 

Thanks for any ideas 

 

 

 

 

0 Kudos
Message 1 of 12
(4,415 Views)

Nobody has any ideas on the subject ?

Nobody has note the same behaviour ?

 

One more little information : I've noticed that the mxssvr service goes down 24D and 20H (approximatively)  after being started.

 

Thank you in advance for any ideas ...

0 Kudos
Message 2 of 12
(4,270 Views)

One interesting observation:

 

2147483648 (2^31) ms == 24 days, 20 hours, 31 minutes, 23 seconds.

——
Brandon Streiff
ni.com/compactdaq · ni.com/daq
0 Kudos
Message 3 of 12
(4,267 Views)

Good analysis ...

 

But I haven't the sources of mxssvr to search in this way !!

 

One (maybe) interesting point :

the NISSPALSharedDataSegment (can be found in /tmp/nipal) has update it mtime with (approximately) the date and time of the "crash" of mxssvr service.

 

 

 

0 Kudos
Message 4 of 12
(4,230 Views)

The NISSPALSharedDataSegment is just a space to share data across processes that use nipal (i.e., pretty much every piece of NI software). I'm not sure that the mtime being the time of the crash has any significance above 'it was at this time that we stopped writing to it, because we crashed.'

 

Unfortunately, I've not had the opportunity to work with the Linux port of DAQmx, so I'm mostly grasping at straws here. I did, however, file Corrective Action Request #247237  with the group that maintains mxssvr to make sure they're aware of the issue so they can evaluate it.

——
Brandon Streiff
ni.com/compactdaq · ni.com/daq
0 Kudos
Message 5 of 12
(4,220 Views)

Thanks for your help ... every help is precious !!

 

For my part, I think I will try with a suse or mandriva distro ... just to see ...

But I'm a bit lazy to try this ... 'cause I need to wait for ... 1 month to check the result !

 

 

0 Kudos
Message 6 of 12
(4,217 Views)

You can also try upgrading the low-level components if SuSE or Mandriva show the same behavior. Perhaps a fix was made after the DAQmx 8.0.1 release, and installing a newer Linux driver that uses the same low-level components as DAQmx will resolve the crash. My recommendation is the NI-VISA 5.0 Run-Time Engine:

 

NI-VISA Run-Time Engine 5.0

http://joule.ni.com/nidu/cds/view/p/id/2044/lang/en

NI-VISA Run-Time Engine 5.0

Joe Friedchicken
NI Configuration Based Software
Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
0 Kudos
Message 7 of 12
(4,211 Views)

I will try this ...

See you next month for the results 😉

0 Kudos
Message 8 of 12
(4,206 Views)

Any updates on this? Any luck reproducing with a different distribution?

 

Another possible line of attack: The original post mentioned that the /tmp/pal directory was being skipped for deletion. MXS also uses the /tmp directory on Linux to store a shared memory map file (the filename will contain "MXS:EventSharedMemory"). The code was written under the assumption that the directory would only be wiped during system reboots and not while MXS was up and running. Any chance these files were being wiped with MXS running in the original scenario?

 

 

 

0 Kudos
Message 9 of 12
(4,064 Views)

Hi,

 

Tests runnings ... I've started my tests on 14/09 .. need to wait for 25 days (one week remaining approximatively).

Thanks for the tip on /tmp I will check this asap (I'll need to find another machine to start this new test ;-))

 

Another thing (totally changing of subject): to get round this problem, I'm restarting the mxssvr service.

Sometimes stopping the service can fail. It's due to a little bug in the /etc/initd.d/mxssvr file

 

 

serviceProcessNumber=`ps -weo pid,cmd | grep $1 | head -n 1 | awk '{print $1 }'` &> /dev/null

the "grep $1 | head -n 1" can return the pid of the grep;

It will be better to do :

 

 

serviceProcessNumber=`ps -weo pid,cmd | grep $1 | grep -v grep | awk '{print $1 }'` &> /dev/null

 

See you later for the result of my tests ...

 

 

0 Kudos
Message 10 of 12
(4,047 Views)