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!
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
On Tue, Dec 29, 2015 at 1:10 PM, Greg Bailey gbailey@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.
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:24 PM, Joseph L. Casale <jcasale@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@centos.org https://lists.centos.org/mailman/listinfo/centos
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@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.
Instead of converting the sysv script, you could trivially write your own, the following was tested against about 6 SNMP queries, the service stops and starts as expected. You may want to purge the sysv remnants.
# cat /etc/systemd/system/lsi_mrdsnmpd.service [Unit] Description=LSI SNMP Agent startup/shutdown script
Requires=network.target Requires=snmpd.service
After=network.target After=snmpd.service
[Service] Type=forking ExecStart=/etc/lsi_mrdsnmp/lsi_mrdsnmpagent -c /etc/snmp/snmpd.conf
[Install] WantedBy=multi-user.target
hth, jlc
On Tue, Dec 29, 2015 at 5:23 PM, Joseph L. Casale <jcasale@activenetwerx.com
wrote:
Instead of converting the sysv script, you could trivially write your own, the following was tested against about 6 SNMP queries, the service stops and starts as expected.
That's certainly an option. One that I was prepared to resort to. But curiosity has the best of me ... I would like to know why the SysV generator didn't do its job.
And I wasn't able to find any "generated" unit files from those Dell OpenManage SysV scripts either.
You may want to purge the sysv remnants.
# cat /etc/systemd/system/lsi_mrdsnmpd.service [Unit] Description=LSI SNMP Agent startup/shutdown script
Requires=network.target Requires=snmpd.service
After=network.target After=snmpd.service
[Service] Type=forking ExecStart=/etc/lsi_mrdsnmp/lsi_mrdsnmpagent -c /etc/snmp/snmpd.conf
[Install] WantedBy=multi-user.target
hth, jlc
I appreciate the effort. You took some of the fun out of it for me ... less for me to write. :-)
On 30 Dec 2015 00:55, "Mike - st257" silvertip257@gmail.com wrote:
On Tue, Dec 29, 2015 at 5:23 PM, Joseph L. Casale <
jcasale@activenetwerx.com
wrote:
Instead of converting the sysv script, you could trivially write your
own,
the following was tested against about 6 SNMP queries, the service stops and starts as expected.
That's certainly an option. One that I was prepared to resort to. But curiosity has the best of me ... I would like to know why the SysV generator didn't do its job.
And I wasn't able to find any "generated" unit files from those Dell OpenManage SysV scripts either.
The generators all run automatically when systemd reloads config.
The transient unit files created are in /var/run ...
Best way to see this is using systemctl (status|cat|show) <servicename> ...
I expect if you do this for your failing service you'll get a better understanding of what's going on.
Consolidating my reply to both James and Gordon in one message.
On Wed, Dec 30, 2015 at 2:38 AM, James Hogarth james.hogarth@gmail.com wrote:
On 30 Dec 2015 00:55, "Mike - st257" silvertip257@gmail.com wrote:
On Tue, Dec 29, 2015 at 5:23 PM, Joseph L. Casale <
jcasale@activenetwerx.com
wrote:
Instead of converting the sysv script, you could trivially write your
own,
the following was tested against about 6 SNMP queries, the service stops and starts
as
expected.
That's certainly an option. One that I was prepared to resort to. But curiosity has the best of me
...
I would like to know why the SysV generator didn't do its job.
And I wasn't able to find any "generated" unit files from those Dell OpenManage SysV scripts either.
The generators all run automatically when systemd reloads config.
The transient unit files created are in /var/run ...
Thanks. I located a few generated ones in /var/run/systemd/generator.late/ But not one for lsi_mrdsnmpagent
Best way to see this is using systemctl (status|cat|show) <servicename> ...
I expect if you do this for your failing service you'll get a better understanding of what's going on.
~]# systemctl status lsi_mrdsnmp.service ● lsi_mrdsnmp.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
~]# systemctl cat lsi_mrdsnmp.service Unit lsi_mrdsnmp.service is not loaded: No such file or directory
~]# systemctl show lsi_mrdsnmp.service | egrep 'Name|Load' Names=lsi_mrdsnmp.service LoadState=not-found LoadError=org.freedesktop.DBus.Error.FileNotFound "No such file or directory"
Thanks for the assistance.
On 30 December 2015 at 14:23, Mike - st257 silvertip257@gmail.com wrote:
Consolidating my reply to both James and Gordon in one message.
On Wed, Dec 30, 2015 at 2:38 AM, James Hogarth james.hogarth@gmail.com wrote:
On 30 Dec 2015 00:55, "Mike - st257" silvertip257@gmail.com wrote:
On Tue, Dec 29, 2015 at 5:23 PM, Joseph L. Casale <
jcasale@activenetwerx.com
wrote:
Instead of converting the sysv script, you could trivially write your
own,
the following was tested against about 6 SNMP queries, the service stops and starts
as
expected.
That's certainly an option. One that I was prepared to resort to. But curiosity has the best of me
...
I would like to know why the SysV generator didn't do its job.
And I wasn't able to find any "generated" unit files from those Dell OpenManage SysV scripts either.
The generators all run automatically when systemd reloads config.
The transient unit files created are in /var/run ...
Thanks. I located a few generated ones in /var/run/systemd/generator.late/ But not one for lsi_mrdsnmpagent
Best way to see this is using systemctl (status|cat|show) <servicename>
...
I expect if you do this for your failing service you'll get a better understanding of what's going on.
~]# systemctl status lsi_mrdsnmp.service ● lsi_mrdsnmp.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
~]# systemctl cat lsi_mrdsnmp.service Unit lsi_mrdsnmp.service is not loaded: No such file or directory
~]# systemctl show lsi_mrdsnmp.service | egrep 'Name|Load' Names=lsi_mrdsnmp.service LoadState=not-found LoadError=org.freedesktop.DBus.Error.FileNotFound "No such file or directory"
Can you pastebin the init script by any chance? I wonder if it's actually a properly written init script or if it's bad enough that the generator fails to parse it ...
On Wed, Dec 30, 2015 at 10:06 AM, James Hogarth james.hogarth@gmail.com wrote:
Best way to see this is using systemctl (status|cat|show) <servicename>
...
I expect if you do this for your failing service you'll get a better understanding of what's going on.
~]# systemctl status lsi_mrdsnmp.service ● lsi_mrdsnmp.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
~]# systemctl cat lsi_mrdsnmp.service Unit lsi_mrdsnmp.service is not loaded: No such file or directory
~]# systemctl show lsi_mrdsnmp.service | egrep 'Name|Load' Names=lsi_mrdsnmp.service LoadState=not-found LoadError=org.freedesktop.DBus.Error.FileNotFound "No such file or directory"
Can you pastebin the init script by any chance? I wonder if it's actually a properly written init script or if it's bad enough that the generator fails to parse it ...
Yes - here is a pastebin with that script.
And there was an error on line 130 ... or line 133 of the pastebin -- which I already fixed. ;-) (I verified the typo against the contents of the RPM from LSI to be certain.) if ( "$rhel_ver" == "1" && "oel_ver" == "0" ) ; then should have been if ( "$rhel_ver" == "1" && "$oel_ver" == "0" ) ; then
On 30 December 2015 at 15:25, Mike - st257 silvertip257@gmail.com wrote:
On Wed, Dec 30, 2015 at 10:06 AM, James Hogarth james.hogarth@gmail.com wrote:
Best way to see this is using systemctl (status|cat|show)
<servicename> > > ... > > > > > > I expect if you do this for your failing service you'll get a better > > > understanding of what's going on. > > > > > > ~]# systemctl status lsi_mrdsnmp.service > > ● lsi_mrdsnmp.service > > Loaded: not-found (Reason: No such file or directory) > > Active: inactive (dead) > > > > ~]# systemctl cat lsi_mrdsnmp.service > > Unit lsi_mrdsnmp.service is not loaded: No such file or directory > > > > ~]# systemctl show lsi_mrdsnmp.service | egrep 'Name|Load' > > Names=lsi_mrdsnmp.service > > LoadState=not-found > > LoadError=org.freedesktop.DBus.Error.FileNotFound "No such file or > > directory" > > > > > > > Can you pastebin the init script by any chance? I wonder if it's actually a > properly written init script or if it's bad enough that the generator > fails to parse it ...
Yes - here is a pastebin with that script.
And there was an error on line 130 ... or line 133 of the pastebin -- which I already fixed. ;-) (I verified the typo against the contents of the RPM from LSI to be certain.) if ( "$rhel_ver" == "1" && "oel_ver" == "0" ) ; then should have been if ( "$rhel_ver" == "1" && "$oel_ver" == "0" ) ; then
That doesn't even make sense ... if it's both rhel and oel version 7 then systemctl start <Service> ... :/
Some lovely samples from it: #A function to stop a program. statuscheck() {
Let's import the standard distro function library! then ... mykillproc() {
Okay we might have a pid we think ... better kill it ...
kill -TERM $pid usleep 200000 if ps h $pid >/dev/null >/dev/null 2>&1 ; then sleep 1 if ps h $pid >/dev/null >/dev/null 2>&1 ; then sleep 3 ...
Hmm we have a snmpd dependency... if [ -x /etc/init.d/snmpd ] ; then /etc/init.d/snmpd start
./twitch && ./vomit
That's so badly written it wouldn't surprise me if it just barfed and gave up ...
According to https://github.com/systemd/systemd/blob/master/src/sysv-generator/sysv-gener... though the journal (or syslog) should contain a Failed to create unit file <foo> if it couldn't translate it though ...
I'd seriously just give up on that and do the 3-5 line systemd unit that is soo much cleaner ... you could even have a proper snmpd.service dependency in place then!
On Wed, Dec 30, 2015 at 10:47 AM, James Hogarth james.hogarth@gmail.com wrote:
Can you pastebin the init script by any chance? I wonder if it's
actually a
properly written init script or if it's bad enough that the generator fails to parse it ...
Yes - here is a pastebin with that script.
And there was an error on line 130 ... or line 133 of the pastebin --
which
I already fixed. ;-) (I verified the typo against the contents of the RPM from LSI to be certain.) if ( "$rhel_ver" == "1" && "oel_ver" == "0" ) ; then should have been if ( "$rhel_ver" == "1" && "$oel_ver" == "0" ) ; then
That doesn't even make sense ... if it's both rhel and oel version 7 then systemctl start <Service> ... :/
Some lovely samples from it: #A function to stop a program. statuscheck() {
Let's import the standard distro function library! then ... mykillproc() {
Okay we might have a pid we think ... better kill it ...
kill -TERM $pid usleep 200000 if ps h $pid >/dev/null >/dev/null 2>&1 ; then sleep 1 if ps h $pid >/dev/null >/dev/null 2>&1 ; then sleep 3 ...Hmm we have a snmpd dependency... if [ -x /etc/init.d/snmpd ] ; then /etc/init.d/snmpd start
./twitch && ./vomit
That's so badly written it wouldn't surprise me if it just barfed and gave up ...
I guess that syntax error I found should have been a tip-off. Thanks for analyzing LSI's SysV init script. ;-)
I didn't take the time to do that before you asked for a pastebin. I appreciate the help.
According to
https://github.com/systemd/systemd/blob/master/src/sysv-generator/sysv-gener... though the journal (or syslog) should contain a Failed to create unit file <foo> if it couldn't translate it though ...
I briefly looked at (and grepped) logs and didn't find a message about failing to create unit file.
I'd seriously just give up on that and do the 3-5 line systemd unit that is soo much cleaner ... you could even have a proper snmpd.service dependency in place then!
Sounds like the best path.
Thank you everyone.
On 12/29/2015 01:13 PM, Mike - st257 wrote:
( Has Red Hat even built x86 libraries for x86_64 since RHEL7 no longer supports x86? )
Yes. There's no 32 bit kernel, so no 32 bit installation media, but running 32 bit applications is still supported.
Did the logs provide any useful information? (systemctl status lsi_mrdsnmpd)
-
Gordon Messmer -
Greg Bailey -
James Hogarth -
Joseph L. Casale -
Mike - st257