The issue here is that even though RHEL is theoretically binary-compatible with SL, they claim that any issues with their software on an unsupported platform isn't something they can even talk to you about.  They also said that it's unlikely that this issue was happening on RHEL5.3, given that so many of their clients run it without any problems.  So, likely this IS an SL bug, but it's not one I can point my finger at a setting or tweak or configuration difference between RHEL5.3 and SL5.3 to explain it.

If anyone can find a setting to tweak or a library to upgrade/downgrade/replace, I would love to try any solutions people have.  I've run out of steam with my googling, and switching to RHEL5.3 isn't really an option.

-Aaron

On Apr 23, 2010, at 12:43 PM, Boris Wagner wrote:

> Hi 
> You always have to tell support people that you run Red Hat Enterprise Linux, not SL, not CentOS, it's not on their checklist and you're out. Although they're usually binary compatible. 
> 
> At least in  my experience.
> 
> 	Boris
> 
> On 23.04.2010, at 19:33, Connie Sieh wrote:
> 
>> On Fri, 23 Apr 2010, Aaron van Meerten wrote:
>> 
>>> --Apple-Mail-1--470646227
>>> Content-Transfer-Encoding: quoted-printable
>>> Content-Type: text/plain;
>>> 	charset=us-ascii
>>> 
>>> I am having this exactly problem.  My solution has been to re-run =
>>> srvadmin-services.sh start again anytime these daemons stop running.  =
>>> They will then continue to run for some short period of time before =
>>> failing again.
>>> 
>>> I have only one node that refuses to ever respond to these commands, and =
>>> the daemons quit without any warning.
>>> 
>>> I called Dell support with regards to this topic, and was told basically =
>>> that since SL5.3 is NOT a support platform, that no one from Linux =
>> 
>> So what is a supported platform?
>> 
>> -Connie Sieh
>>> Services was going to talk to me about this topic.  He also told me that =
>>> I'd have to purchase a higher level of support, as the baseline support =
>>> contract only supports the hardware and doesn't promise anything about =
>>> the software at all.
>>> 
>>> So, let me know if you come up with anything resembling a solution to =
>>> this.  My work-around with srvadmin-services.sh is not elegant, and =
>>> isn't a sure-fire solution either.
>>> 
>>> Cheers,
>>> 
>>> -Aaron van Meerten
>>> MWT2
>>> 
>>> On Apr 23, 2010, at 11:47 AM, Michael Tiernan wrote:
>>> 
>>>> Hello everyone.
>>>> =20
>>>> I'm running into a problem and I'm wondering if anyone has seen =
>>> anything very similar or if I'm breaking new ground with it.
>>>> =20
>>>> I have a system that I just got, it's a Dell PE R710 with the new H700 =
>>> RAID card. I installed it with SL5.3 (Our current version.) and when =
>>> loading the srvadmin tools (directly from the Dell site) I have been =
>>> finding that the daemons don't continue to run. Here's a small snippet =
>>> from my system log:
>>>> =20
>>>> Apr 23 12:33:50 xxxxxxxx Server Administrator: Instrumentation Service =
>>> EventID: 1001  Server Administrator startup complete
>>>> Apr 23 12:33:51 xxxxxxxx dataeng: dsm_sa_eventmgrd shutdown succeeded
>>>> Apr 23 12:33:58 xxxxxxxx dataeng: dsm_sa_datamgrd shutdown succeeded
>>>> Apr 23 12:33:59 xxxxxxxx instsvcdrv: dell_rbu device driver unloaded
>>>> =20
>>>> After the start process finishes (first line), the next three lines =
>>> show the daemons shutting down. It continues to try to respawn the =
>>> services only to have them continue to die.
>>>> =20
>>>> The start sequence is:
>>>> /opt/dell/srvadmin/sbin/srvadmin-service.sh start
>>>> [short pause........]
>>>> omreport storage vdisk
>>>> [a normal output from the omreport about vdisks.]
>>>> [another short pause.....]
>>>> omreport storage vdisk
>>>> [error, can't find any controllers]
>>>> =20
>>>> It is at this point, you can see the dataeng trying to restart the =
>>> dsm_sa daemons over and over again. (Clarification, they start then =
>>> stop.)
>>>> =20
>>>> I built a RHEL5.3 system and the tools don't seem to be having a =
>>> problem.
>>>> =20
>>>> Before I go digging into it much more I thought I'd ask if anyone else =
>>> has had any experience with this problem.
>>>> =20
>>>> Thanks for everyone's time and use of the forum.
>>>> =20
>>>> --=20
>>>> <<  MCT>>    Michael C Tiernan.   xmpp:[log in to unmask]
>>>> MIT - Laboratory for Nuclear Science - http://www.lns.mit.edu
>>>> High Perf Research Computing Facility at The Bates Linear Accelerator
>>>> "Bit-smashing your bits better than anyone can!"
>>>> =20
>>>> =20
>>> 
>