05-04-2010 09:50 AM
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
09-01-2010 08:31 AM
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 ...
09-01-2010 09:45 AM
One interesting observation:
2147483648 (2^31) ms == 24 days, 20 hours, 31 minutes, 23 seconds.
09-02-2010 02:38 AM
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.
09-02-2010 08:31 AM
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.
09-02-2010 09:06 AM
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 !
09-02-2010 09:47 AM
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
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)
09-02-2010 09:53 AM
I will try this ...
See you next month for the results 😉
10-04-2010 02:48 PM
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?
10-05-2010 12:42 AM
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 ...