On boot to multiuser mode, the system hangs just before the "login:"
          prompt is displayed. Telnetting to the system succeeds and the
          process table shows a sleep 1000000 process running. When the sleep
          process is killed, the login prompt appears and the system functions
          normally.

          The sleep command is called by the script /etc/rc2. This is the
          script that runs when the server goes into multiuser state. The
          addition of the sleep 1000000 to the script is only present in SCO
          OpenServer 5.0.5. It addresses some timing problems with drivers
          starting from this script. With OpenServer 5.0.5, the startup
          scripts can all start in parallel, making the startup sequence
          faster. However, a script failure (hang) can completely hang the
          startup process if one script hangs. With the addition of the
          sleep command, if a third-party device driver (installed in
          /etc/idrc.d for example) were to lock, then the processor would
          still be kept busy running the sleep command until the offending
          device driver timed out. This prevents the server from completely
          hanging.

          The root cause of this hang is the incomplete startup of a
          third-party driver.  The sleep command hanging is a symptom of the
          root problem.

          To discover which driver startup script is causing the hang, put
          echo statements in the top of each of the startup scripts in
          /etc/rc2.d.  The echo statement should echo the name of the script
          executing.  The third-party device driver startup script last echoed
          before the hang will be the culprit. Typically, this will be a
          script from the /etc/idrc.d directory.

          Once the offending startup script has been identified, it can be
          moved to the /etc/rc script so it is started after the system boots
          to multiuser mode. Also, the script can be examined closely to
          determine the cause of the hang.

          To work around the problem, eliminate the sleep commands from the
          rc2 script as follows:

          Edit the /etc/rc2 script, comment out the lines executing the
          sleep command:

      # PC 6300+ Style Installation-execute rc scripts from driver packages
      if [ -d /etc/idrc.d ] then
      #
      # sleeps only present from 5.0.5 and present for driver timing issues
      # Removed SB 28/07/99
      #
      # sleep 1000000>/dev/null 2>&1 &
      # P=$!
      {         for f in `ls /etc/idrc.d/* 2>/dev/null`
                do
                    if [ -s ${f} ] then
                            /bin/sh ${f}
                    fi
                done
                # kill -ALRM $P
      }   2>&1 | { $LOGCMD & } 2>/dev/null
      # wait $P fi

          The less extreme change of eliminating logging can sometimes be
          enough to address the problem. The results of scripts being run
          in /etc/idrc.d get recorded in /usr/adm/rc2.log. This write is
          sometimes the cause of the hang. You can stop this from happening
          with the following changes to the /etc/rc2 script (adding the '#'
          before the { $LOGCMD & }):

      # PC 6300+ Style Installation - execute rc scripts from driver
      packages
      if [ -d /etc/idrc.d ] then
            sleep 1000000 >/dev/null 2>&1 &
            P=$!
            {
              for f in `ls /etc/idrc.d/* 2>/dev/null`
              do
                    if [ -s  ${f} ] then
                      /bin/sh ${f}
                    fi
              done
              kill -ALRM $P
            } 2>&1 # | { $LOGCMD & } 2>/dev/null
            wait $P fi

          If the problem still remains, telnet to the server during the hang
          and take note of process table contents.  Identify the driver
          startup process that is hanging and add a set -x statement to the
          script. Start it manually to see when the lock happens.