Init script for AOE not working

Hi,

I got the OpenSuse 13.2 up and running and installed the package vblade on it. This package doesn’t como with a init script but I already have one working script on a Suse enterprise Linux 11 and tryed to use iT on the new OpenSuse.

I put the script at /etc/init.d/vblade and created a link “/usr/sbin/rcvblade -> /etc/init.d/vblade”, then used the chkconfig command to enable the init script, but it wont start, it only prints the following message and exits.

olimpo:~ # /etc/init.d/vblade start
redirecting to systemctl start vblade.service
olimpo:~ #

This is the script file I’m trying to run

#!/bin/sh
# 
# Init script for vblade (ATA over Ethernet daemon)
# 
# chkconfig: - 30 70
# description: vblade AoE daemon
# 
# processname: vblade
# config: /etc/vblade.conf
# 
# Shamelessly hacked together from other init scripts (sshd, mostly)
# 
# Script grabbed from http://cvs.fedoraproject.org/viewvc/EL-5/vblade/vblade.init?view=co
### BEGIN INIT INFO
# Provides: vbladed
# Required-Start: $network $syslog
# Required-Stop: $network $syslog
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Description: Start the vbladed daemon
### END INIT INFO

#. /lib/lsb/init-functions
. /etc/rc.status

# Shell functions sourced from /etc/rc.status:
#      rc_check         check and set local and overall rc status
#      rc_status        check and set local and overall rc status
#      rc_status -v     ditto but be verbose in local rc status
#      rc_status -v -r  ditto and clear the local rc status
#      rc_failed        set local and overall rc status to failed
#      rc_reset         clear local rc status (overall remains)
#      rc_exit          exit appropriate to overall rc status

RETVAL=0
prog=vblade

# First reset status of this service
rc_reset

spawn_vblade() {
  ALLOWMACS=""
   -n "$5" ] && ALLOWMACS="-m $5"
  ID="$1-e$2.$3"
  PID_FILE=/var/run/$prog/${ID}.pid
  $prog $ALLOWMACS $2 $3 $1 $4 >> /var/log/$prog.log 2>&1 &
  pid=$!
  RETVAL=$?
  echo $pid > $PID_FILE
  echo -n $"$4 (e$2.$3@$1) [pid $pid]"
   "$RETVAL" = 0 ] && rc_status -v || rc_failed 1
  echo
}

start() {
  echo $"Starting up $prog: "
  if  `grep -vc '^#\|^$' /etc/$prog.conf` != 0 ]
  then
    grep -v '^#' /etc/$prog.conf | sed -e 's/ / /g' -e 's/  / /g' | while read line
    do
      spawn_vblade $line
    done
    touch /var/lock/subsys/$prog
  else
    echo -n "empty $prog.conf?"
    rc_failed 3
    rc_status -v
    echo
  fi
}

startdisk() {
  echo $"Starting up disk $1: "
  if  `grep -vc '^#\|^$' /etc/$prog.conf` != 0 ]
  then
    grep -w "$1" /etc/$prog.conf | grep -v "#" | grep -v grep | sed -e 's/      / /g' -e 's/  / /g' | while read line
    do
      DEVICE=`echo $line | awk -F" " '{print $4}'`
      if  -b $DEVICE ]];then
        spawn_vblade $line
        
      else
        echo
        echo -n "No such device $DEVICE"
        #failure
        rc_failed 1
        rc_status -v
        echo
        echo
      fi
    done
    touch /var/lock/subsys/$prog
  fi
}

stop() {
  echo -n $"Shutting down $prog: "
  for pidfile in `ls /var/run/$prog/*.pid`
  do
    kill -9 `cat $pidfile`
    rm -f $pidfile
  done
  #success
  rc_status -v
  echo
  rm -f /var/lock/subsys/$prog
}

stopdisk() {
  echo -n $"Shutting down disk $1: "
  grep "$1" /etc/$prog.conf | grep -v "#" | grep -v grep | sed -e 's/   / /g' -e 's/  / /g' | while read line
  do
  ID=`echo $line | awk -F" " '{print $1"-e"$2"."$3}'`
  pidfile=/var/run/$prog/${ID}.pid

  kill -9 `cat $pidfile`
  rm -f $pidfile
  done
  #success
  rc_status -v
  echo
  rm -f /var/lock/subsys/$prog
}

case "$1" in
        start)
                start
                ;;
        startdisk)
                startdisk $2
                ;;
        stop)
                stop
                ;;
        stopdisk)
                stopdisk $2
                ;;
        restart)
                stop
                start
                ;;
        reload)
                # yes, this sucks, but the vblade processes die on SIGHUP
                stop
                start
                ;;
        condrestart)
                if  -f /var/lock/subsys/$prog ]; then
                  stop
                  # avoid race
                  sleep 3
                  start
                fi
                ;;
        status)
                status $prog
                RETVAL=$?
                ;;
        *)
                echo $"Usage: $0 {start|startdisk|stop|stopdisk|restart|reload|condrestart|status}"
                RETVAL=1
esac
exit $RETVAL


and tis is a sample of the config file

# network_device shelf slot file||disk_partition mac,mac,mac]]
#=================================================================================
#
em1 3 0 /dev/sdb1

The script should read some lines from its config file (/etc/vblade.conf) and spawn the vblade process for each configured disk, but I found out that when it goes to source the file /etc/rc_status it doesn’t come back and gives the message repported above.

I tryed to spawn the process by hand for one disk and it worked.

olimpo:~ # vblade 3 0 em1 /dev/sdb1
pid 3629: e3.0, 1952446464 sectors O_RDWR

Am I missing something? What should I do to get it working?

Best Regards,
Carlos

openSUSE dos not use sysvinit (that uses init.d, and the symlinks, etc.) anymore. It uses systemd.

Now there is some backwords compatibility build in in systemd, but I do not know how much and if that covers your case. But when you seemingly try to adapt something to openSUSE 13.2, my advice would be to adapt to systemd. Better for the future.

SysV is dead and buried as far as 13.2 goes, I would create a systemd service file for your application, something in the lines of;


[Unit]
Description=vblade is awesome!
After=network.target

[Service]
Type=simple
EnvironmentFile=/etc/vblade.conf
ExecStart=/usr/sbin/vblade "$VBLADE_PARAMETERS"
Restart=on-failure
PIDFile=/var/run/vblade.pid


[Install]
WantedBy=multi-user.target

Type may need to be adjusted depending on how the service works, if it “forks” itself in the background or just runs as a simple service - I’m not familiar with the service itself so I can’t say. The .conf would contain the line VBLADE_PARAMETERS=“3 0 em1 /dev/sdb1”

Save the file in /usr/lib/systemd/system/vblade.service, issue systemctl daemon-reload since the service files have changed and fire it up with systemctl start vblade

Something like that - might give you some ideas how to get the job done :stuck_out_tongue:

On 2015-01-20 10:06, Miuku wrote:
>
> SysV is dead and buried as far as 13.2 goes, I would create a systemd
> service file for your application, something in the lines of;

No need, init.d scripts are supported without modification. The trick is
in this line of all those scripts:


. /etc/rc.status

which handles the redirection to systemctl. And systemd often keeps
silent about success of the service start.

The OP does this:


olimpo:~ # /etc/init.d/vblade start
redirecting to systemctl start vblade.service
olimpo:~ #

That is fine. Just run now “rcvblade status” and find out what
happened… Maybe it is already running.

Look, this is 13.1, where sshd is still an initd script:


Telcontar:~ # rcsshd stop
redirecting to systemctl stop sshd.service
Telcontar:~ # rcsshd start
redirecting to systemctl start sshd.service
Telcontar:~ #

See? it says nothing, yet both command succeeded.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Yes, there is a need. We would not advise this when there wouldn’t be a need. Less and less people will understand what that old Sysv stuff is and thus sticking to the old way will be a dead alley also when asking help. The OP is starting more or less fresh on this system. Thus our advice to use todays way, to be ready for the near future. And in the same time to learn something about systemd.

True.dat.

However, IMHO, for future it’s still better to write a proper systemd service file for it and then you’ll save some headaches down the road :slight_smile:

On 2015-01-20 15:06, Miuku wrote:
>
> robin_listas;2690253 Wrote:
>> See? it says nothing, yet both command succeeded.
> True.dat.
>
> However, IMHO, for future it’s still better to write a proper systemd
> service file for it and then you’ll save some headaches down the road
> :slight_smile:

But that is asking a large effort from the OP, telling him to create a
service file, instead of simply using the existing init script. It is
the maintainers of that AOE package who should shoulder the effort of
migrating to systemd, not the user.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

The thing is there is no init file - the OP made one himself.

So he might as well do one since he’ll need it for SLES12 in the future.

On 2015-01-20 17:46, Miuku wrote:
>
> robin_listas;2690269 Wrote:
>> It is the maintainers of that AOE package who should shoulder the effort
>> of migrating to systemd, not the user.
> The thing is there is no init file - the OP made one himself.

Ah, then… :slight_smile:

I understand he simply copied it from an SLES install. Dunno who wrote
it originally, copied from Fedora, or he hacked it.

> So he might as well do one since he’ll need it for SLES12 in the future.

I’m unsure about the “need”. That it is or will be advantageous, yes,
sure. But I think that those scripts will be working for many years, as
there are many old packages around, some proprietary, that take eons to
adapt.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

I assume you have problems with the word “need”.

While at one side you say there is “no need” to adapt to systemd, we say there is.

On the other side, we do not say he “needs” to adapt, we only say we advise him to do so.

Your advice may be to sit down and wait for eons, but even after how long the eons may be, the end of it will allways come as a surprise and allways at a moment you can not afford your service being down. At this moment in time, he is aware of it and most probably he has now the opportunity to implement it (while he is installing a new system). And when done, he not only may sit down, but even lie down with the reassuring idea he is ready for the eons to come, where not only the compatibility with the old, but also the knowledge of the old will vanish at an uknown moment.