Home/ Questions/Q 9123081
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T06:15:12+00:00

I am starting ftam server ( ft820.rc on CentOS 5) using bash version bash

  • 0

I am starting ftam server (ft820.rc on CentOS 5) using bash version bash 3.0 and I am having an issue with starting it from the script, namely in the script I do

ssh -nq root@$ip /etc/init.d/ft820.rc start

and the script won’t continue after this line, although when I do on the machine defined by $ip

/etc/init.d/ft820.rc start

I will get the prompt back just after the service is started.

This is the code for start in ft820.rc

  SPOOLPATH=/usr/spool/vertel
  BINPATH=/usr/bin/osi/ft820
  CONFIGFILE=${SPOOLPATH}/ffs.cfg

  # Set DBUSERID to any value at all. Just need to make sure it is non-null for
  # lockclr to work properly.
  DBUSERID=
  export DBUSERID

  # if startup requested then ...
  if [ "$1" = "start" ]
  then
          mask=`umask`
          umask 0000

          # startup the lock manager
          ${BINPATH}/lockmgr -u 16

          # update attribute database
          ${BINPATH}/fua ${CONFIGFILE} > /dev/null

          # clear concurrency locks
          ${BINPATH}/finit -cy ${CONFIGFILE} >/dev/null

          # startup filestore
          ${BINPATH}/ffs ${CONFIGFILE}
          if [ $? = 0 ]
          then
                  echo Vertel FT-820 Filestore running.
          else
                  echo Error detected while starting Vertel FT-820 Filestore.
          fi

          umask $mask
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I repost here (on request of @Patryk) what I put in the comments on the question:

    “is it the same when doing the ssh… in the commandline? ie, can you indeed connect without entering a password, using the pair of private_local_key and the corresponding public_key that you previously inserted in the destination root@$ip:~/.ssh/authorized_keys file ? – Olivier Dulac 20 hours ago “

    “you say that, at the commandline (and NOT in the script) you can ssh root@…. and it works without asking for your pwd ? (ie, it can then be run from a script?) – Olivier Dulac 20 hours ago “

    ” try the ssh without the ‘-n’ and even without -nq at all : ssh root@$ip /etc/init.d/ft820.rc start (you could even add ssh -v , which will show you local (1:) and remote (2:) events in a very verbose way, helping in knowing where it gets stuck exactly) – Olivier Dulac 19 hours ago “

    “also : before the “ssh…” line in the script, make another line with, for example: ssh root@ip “set ; pwd ; id ; whoami” and see if that works and shows the correct information. This may help be sure the ssh part is working. The “set” part will also show you the running shell (ex: if it contains BASH= , you’re running bash. Otherwise SHELL=… should give a good hint (sometimes not correct) about which shell gets invoked) – Olivier Dulac 19 hours ago “

    ” please try without the ‘-n’ (= run in background and wait, instead of just run and then quit). It it doesn’t work, try adding -t -t -t (3 times) to the ssh, to force it to allocate a tty. But first, please drop the ‘-n’. – Olivier Dulac 18 hours ago “

    Apparently what worked was to add the -t option to the ssh command. (you can go up to put ‘-t -t -t’ to further force it to try to allocate the tty, depending on the situation)

    I guess it’s because the invoked command expected to be run within an interactive session, and so needed a “tty” to be the stdout

    A possibility (but just a wild guess) : the invoked rc script outputs information, but in a buffered environment (ie, when not launched via your terminal), the calling script couldn’t see enough lines to fill the buffer and start printing anything out (like when you do a “grep something | somethings else” in a buffered environment and ctrl+c before the buffer was big enough to display anything : you end up thinking no lines were foudn by the grep, whereas there was maybe a few lines already in the buffer). There is tons to be said about buffering, and I am just beginning to read about it all. forcing ssh to allocate a tty made the called command think it was outputting to a live terminal session, and that may have turned off the buffering and allowed the result to show. Maybe in the first case, it worked too, but you could never see the output?

    • 0