Hello CentOS List,
I have a server that has SysV script supplied by a hardware manufacturer,
which is not functioning properly. From my reading, systemd-sysv-generator
should handle them (like it did for Dell OpenManage software which supplied
SysV init scripts).
/usr/lib/systemd/system-generators/systemd-sysv-generator
Takes no or 3 arguments (it tells me), but I didn't find clear
documentation on this binary.
And no arguments doesn't seem to fix the issue.
The particular software in question is LSI MegaRaid SNMP daemon.
I retrieved the latest version from LSI's site which was provided for EL7.
~]# systemctl lsi_mrdsnmpd.service start
Unknown operation 'lsi_mrdsnmpd.service'.
~]# service lsi_mrdsnmpd start
Reloading systemd: [ OK ]
Starting lsi_mrdsnmpd (via systemctl): Failed to start
lsi_mrdsnmpd.service: Unit lsi_mrdsnmpd.service failed to load: No such
file or directory.
[FAILED]
~]# /etc/init.d/lsi_mrdsnmpd start
Reloading systemd: [ OK ]
Starting lsi_mrdsnmpd (via systemctl): Failed to start
lsi_mrdsnmpd.service: Unit lsi_mrdsnmpd.service failed to load: No such
file or directory.
[FAILED]
~]# /etc/init.d/lsi_mrdsnmpd status
lsi_mrdsnmpagent is stopped
~]# ls -1 /etc/init.d/
dataeng
dsm_om_connsvc
dsm_om_shrsvc
dsm_sa_ipmi
functions
instsvcdrv
lsi_mrdsnmpd
netconsole
network
racsvc
racsvc.sh
README
# in /etc/init.d/README
"Note that traditional init scripts continue to function on a systemd
system. An init script /etc/rc.d/init.d/foobar is implicitly mapped
into a service unit foobar.service during system initialization."
~]# ls -1 /etc/rc.d/init.d/
dataeng
dsm_om_connsvc
dsm_om_shrsvc
dsm_sa_ipmi
functions
instsvcdrv
lsi_mrdsnmpd
netconsole
network
racsvc
racsvc.sh
README
Thoughts as to why systemd didn't "implicitly" handle this SysV
script (and
have it work)?
Suggestions as to where I go from here to properly solve this problem?
Thanks!
--
---~~.~~---
Mike
// SilverTip257 //
On 12/29/2015 10:13 AM, Mike - st257 wrote:> Hello CentOS List, > > I have a server that has SysV script supplied by a hardware manufacturer, > which is not functioning properly. From my reading, systemd-sysv-generator > should handle them (like it did for Dell OpenManage software which supplied > SysV init scripts). > > /usr/lib/systemd/system-generators/systemd-sysv-generator > Takes no or 3 arguments (it tells me), but I didn't find clear > documentation on this binary. > And no arguments doesn't seem to fix the issue. > > The particular software in question is LSI MegaRaid SNMP daemon. > I retrieved the latest version from LSI's site which was provided for EL7. > > > ~]# systemctl lsi_mrdsnmpd.service start > Unknown operation 'lsi_mrdsnmpd.service'.Hi Mike, With "systemctl", the command comes before the name; did you try: systemctl start lsi_mrdsnmpd -Greg
> The particular software in question is LSI MegaRaid SNMP daemon. > I retrieved the latest version from LSI's site which was provided for EL7.While I don't have the answer to your specific question, LSI does does not advertise support for the latest point release and using their current version faults for me after upgrading a host. You say "not functioning properly" but what issues are seeing specifically? Possibly "MegaRAID SNMP AGENT: Error in getting Shared Memory(lsi_mrdsnmpmain)" when starting? I have seen that each time a release of their software is used past a version they state support for... jlc
On Tue, Dec 29, 2015 at 1:10 PM, Greg Bailey <gbailey at lxpro.com> wrote:> On 12/29/2015 10:13 AM, Mike - st257 wrote: > >> Hello CentOS List, >> >> I have a server that has SysV script supplied by a hardware manufacturer, >> which is not functioning properly. From my reading, systemd-sysv-generator >> should handle them (like it did for Dell OpenManage software which >> supplied >> SysV init scripts). >> >> /usr/lib/systemd/system-generators/systemd-sysv-generator >> Takes no or 3 arguments (it tells me), but I didn't find clear >> documentation on this binary. >> And no arguments doesn't seem to fix the issue. >> >> The particular software in question is LSI MegaRaid SNMP daemon. >> I retrieved the latest version from LSI's site which was provided for EL7. >> >> >> ~]# systemctl lsi_mrdsnmpd.service start >> Unknown operation 'lsi_mrdsnmpd.service'. >> > > Hi Mike, > > With "systemctl", the command comes before the name; did you try: > > systemctl start lsi_mrdsnmpd >Well shucks ... looks like I copy+pasted some nonsense rather than actually what I did earlier. Gotta pay more attention. ~]# systemctl start lsi_mrdsnmpd Failed to start lsi_mrdsnmpd.service: Unit lsi_mrdsnmpd.service failed to load: No such file or directory. -- ---~~.~~--- Mike // SilverTip257 //
On Tue, Dec 29, 2015 at 1:24 PM, Joseph L. Casale <jcasale at activenetwerx.com> wrote:> > The particular software in question is LSI MegaRaid SNMP daemon. > > I retrieved the latest version from LSI's site which was provided for > EL7. > > While I don't have the answer to your specific question, LSI does does > not advertise support for the latest point release and using their current > version faults for me after upgrading a host. >This system is not a newly built one, so it was probably on a supported release until a few weeks ago when 7.2 came out. ~]# cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core)> > You say "not functioning properly" but what issues are seeing specifically? > Possibly "MegaRAID SNMP AGENT: Error in getting Shared > Memory(lsi_mrdsnmpmain)" > when starting? >No. That daemon won't start ... reason being systemd unit files. [ I replied to Greg's message just before yours. ]> > I have seen that each time a release of their software is used past a > version they state support for... > > jlc > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >-- ---~~.~~--- Mike // SilverTip257 //
On 12/29/2015 09:13 AM, Mike - st257 wrote:> ~]# /etc/init.d/lsi_mrdsnmpd start > Reloading systemd: [ OK ] > Starting lsi_mrdsnmpd (via systemctl): Failed to start > lsi_mrdsnmpd.service: Unit lsi_mrdsnmpd.service failed to load: No such > file or directory. > [FAILED]IIRC, you'll see that if you have a 64 bit system and try to run a 32-bit binary. Run "ldd" on the binaries you've installed and make sure that all of the required libraries are installed.
On Tue, Dec 29, 2015 at 3:14 PM, Gordon Messmer <gordon.messmer at gmail.com> wrote:> On 12/29/2015 09:13 AM, Mike - st257 wrote: > >> ~]# /etc/init.d/lsi_mrdsnmpd start >> Reloading systemd: [ OK ] >> Starting lsi_mrdsnmpd (via systemctl): Failed to start >> lsi_mrdsnmpd.service: Unit lsi_mrdsnmpd.service failed to load: No such >> file or directory. >> [FAILED] >> > > IIRC, you'll see that if you have a 64 bit system and try to run a 32-bit > binary. Run "ldd" on the binaries you've installed and make sure that all > of the required libraries are installed.[ Gordon, Thanks for pointing this all out. A couple simple steps/information I needed to verify. ] Following what information I've gathered below, I don't think this is relative to needing x86 libraries. ( Has Red Hat even built x86 libraries for x86_64 since RHEL7 no longer supports x86? ) ~]# file /etc/lsi_mrdsnmp/lsi_mrdsnmpagent /etc/lsi_mrdsnmp/lsi_mrdsnmpagent: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.0, not stripped ~]# ldd /etc/lsi_mrdsnmp/lsi_mrdsnmpagent linux-vdso.so.1 => (0x00007ffd29f4a000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fccadc7c000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fccad974000) libm.so.6 => /lib64/libm.so.6 (0x00007fccad671000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fccad45b000) libc.so.6 => /lib64/libc.so.6 (0x00007fccad09a000) /lib64/ld-linux-x86-64.so.2 (0x00007fccade8a000) ~]# /etc/lsi_mrdsnmp/lsi_mrdsnmpagent -c /etc/snmp/snmpd.conf LSI MegaRAID SNMP Agent Ver 3.18.0.2 (Oct 30th, 2012) Started ~]# ps aux | grep lsi root 19446 0.1 0.0 37972 1604 ? Ssl 16:02 0:00 /etc/lsi_mrdsnmp/lsi_mrdsnmpagent -c /etc/snmp/snmpd.conf root 19449 0.0 0.0 21576 584 ? Ss 16:02 0:00 /etc/lsi_mrdsnmp/lsi_mrdsnmpagent -c /etc/snmp/snmpd.conf root 19459 0.0 0.0 112644 952 pts/0 S+ 16:02 0:00 grep --color=auto lsi The binary runs without crashing. -- ---~~.~~--- Mike // SilverTip257 //