Signal 11 errors in Ubuntu Linux

Help
robtweed
2006-12-03
2012-12-29
  • robtweed
    robtweed
    2006-12-03

    I'm finding various situations where Ubuntu Linux (6.06 LAMP server configuration) + GT.M (V5.1-000) gives problems with GT.M processes being thrown out with Signal 11 errors.  I've separately reported one situation which relates to the TCP Client socket.  However I have several other apparently unrelated ones:

    1) If I've logged in as a standard user and GT.M is working just fine, then if I use "su" and change to root, then try mumps -direct, I'm thrown out with a signal 11 error.  CTRL+D to get back to the original user and then I can use mumps -direct just fine

    2) If I retrospectively install the Ubuntu GUI into the LAMP server (which has no GUI installed) [following the instructions at http://www.howtoforge.com/lamp_installation_ubuntu6.06\] then when I reboot after the install, up comes the Ubuntu GUI just fine, I bring up a terminal session, but when I try mumps -direct, I get thrown out with a signal 11

    3) One of the evaluators of the EWD Virtual Appliance which is built with Ubuntu LAMP server + GT.M 5.1-000 (running as a VMWare VM) has reported that when he shut it down with shutdown -h now, next time he booted the Virtual Machine he was getting signal 11 errors every time he tried to do anything with GT.M.  I've never seen it ever get into this state myself, but he's had it happen twice.  The peculiar thing is that in this instance, he can get into GT.M with mumps -direct, but when he tries to do anything in GT.M, it bombs at that point.  I'm getting hold of a copy of his VM to see for myself, but I'm not sure what to really look for that might be causing this problem.

    I know there have been exec-shield related recommendations posted elsewhere, but Ubuntu doesn't have exec-shield installed, and I don't have SE Linux configured to my knowledge (where would I look in Ubuntu to confirm? anyone know?).  So does anyone have any ideas where I should look, and is there a likely common thread in all these signal 11 scenarios?

    Any help greatly appreciated

    Rob Tweed
    M/Gateway Developments Ltd
    http://www.mgateway.com

     
    • robtweed
      robtweed
      2006-12-03

      Tracked down this one:

      3) One of the evaluators of the EWD Virtual Appliance which is built with Ubuntu LAMP server + GT.M 5.1-000 (running as a VMWare VM) has reported that when he shut it down with shutdown -h now, next time he booted the Virtual Machine he was getting signal 11 errors every time he tried to do anything with GT.M.

      It was due to a corrupted .o file that had been FTP'd using ASCII instead of binary transfer.

      However ideas on the others will be still appreciated

      Rob

       
    • K.S. Bhaskar
      K.S. Bhaskar
      2006-12-03

      Rob --

      1. I can't reproduce it:
      sh-3.1$ mumps -dir

      GTM>h
      sh-3.1$ su
      Password:
      bhaskarks:/home/kbhaskar# source /usr/local/gtm_V5.1-000/gtmprofile
      bhaskarks:/home/kbhaskar# mumps -dir

      GTM>h

      Are you setting the environment appropriately after su'ing (e.g., sourcing gtmprofile)?

      2. Since GT.M is a true compiler and M has indirection and Xecute, GT.M requires the ability to execute code in heap space.  Since this is not a common requirement, there are a number of layered applications (SELinux, execshield, grsecurity, etc.) that by default kill a process that attempts this.  If you have looked for exec-shield and SELinux, try grsecurity / pax.   [This has been discussed in another thread; I just don't remember which one exactly.]

      Regards
      -- Bhaskar

       
    • K.S. Bhaskar
      K.S. Bhaskar
      2006-12-03

      In another post, it was reported that:

         execstack -s /usr/local/gtm_V5.1-000/mumps

      enables permission to execute from the stack.  It has also been suggested that you may need
      to execute the following before the above (but try the above before you do the following):

         setsebool -P allowexecstack=1

      The following may also be required:

         chcon -t texrel_shlib_t /usr/local/gtm_V5.1-000/*.so

      -- Bhaskar

       
    • LD Landis
      LD Landis
      2006-12-05

      Hi,

        Another item can be the allowing of code to execute off of the stack.

        For CentOS 3.8, if GT.M gets a signal 11 and the address matches the vaddr,
        this is a hint that the exec-shield is maybe in the way, *not* SELinux.
       
        $ gtm
        %GTM-F-KILLBYSIGSINFO1, GT.M process 27270 has been killed by a signal 11
         at address 0x087AF050 (vaddr 0x087AF050)
        # echo 0 > /proc/sys/kernel/exec-shield
        $ gtm

        GTM>h
        $

        Following is a script that you would place in /etc/init.d and disables the
        exec-shield at boot time. I don't know which init scheme Ubuntu uses (BSD or
        SVID) but for the SVID styled init, put a symbolic link in the /etc/rc#.d/
        for all run-levels #, where you want to allow GT.M to run.

      Cheers,
        --ldl

      $ cat /etc/init.d/exec-shield
      -----------------------------
      #!/bin/bash
      #
      # exec-shield   This sets the exec-shield to 0 so that GT.M can run.
      #
      # Author:       ldl
      #

      . /etc/init.d/functions

      # GT.M enabled (exec-shield 0)
      echo_ENABLED() {
        [ "$BOOTUP" = "color" ] && $MOVE_TO_COL
        echo -n "[ "
        [ "$BOOTUP" = "color" ] && $SETCOLOR_SUCCESS
        echo -n $"ENABLED"
        [ "$BOOTUP" = "color" ] && $SETCOLOR_NORMAL
        echo -n " ]"
        echo -ne "\r"
        return 0
      }

      # GT.M disabled (exec-shield 1)
      echo_DISABLED() {
        [ "$BOOTUP" = "color" ] && $MOVE_TO_COL
        echo -n "[ "
        [ "$BOOTUP" = "color" ] && $SETCOLOR_FAILURE
        echo -n $"DISABLED"
        [ "$BOOTUP" = "color" ] && $SETCOLOR_NORMAL
        echo -n " ]"
        echo -ne "\r"
        return 1
      }

      # Log that GT.M enabled
      enabled() {
        if [ -z "${IN_INITLOG:-}" ]; then
           initlog $INITLOG_ARGS -n $0 -s "GT.M enabled" -e 1
        else
           # silly hack to avoid EPIPE killing rc.sysinit
           trap "" SIGPIPE
           echo "$INITLOG_ARGS -n $0 -s \"GT.M enabled\" -e 1" >&21
           trap - SIGPIPE
        fi
        [ "$BOOTUP" != "verbose" -a -z "$LSB" ] && echo_ENABLED
        return 0
      }

      # Log that GT.M disabled
      disabled() {
        rc=$?
        if [ -z "${IN_INITLOG:-}" ]; then
           initlog $INITLOG_ARGS -n $0 -s "GT.M disabled" -e 1
        else
           trap "" SIGPIPE
           echo "$INITLOG_ARGS -n $0 -s \"GT.M disabled\" -e 1" >&21
           trap - SIGPIPE
        fi
        [ "$BOOTUP" != "verbose" -a -z "$LSB" ] && echo_DISABLED
        return $rc
      }

      OPT="$1"
      if [ $# = 0 ] ; then
        OPT="off"
      fi

      echo -n "Set exec-shield for GT.M: "
      case ${OPT} in
         on)  echo 1 > /proc/sys/kernel/exec-shield ;;
         off) echo 0 > /proc/sys/kernel/exec-shield ;;
         *)   echo "usage: $0: [on|off]" ;;
      esac

      GTM_ENABLED=`cat /proc/sys/kernel/exec-shield`
      [ +${GTM_ENABLED} -eq 0 ] && enabled || disabled
      echo

      # End of exec-shield
      ----------------------------------
      # cd /etc/rc5.d
      # ln -s ../init.d/exec-shield

      $ ls -l /etc/rc5.d/
      lrwxrwxrwx    1 root     root           21 Sep 25 13:41 S09exec-shield -> ../init.d/exec-shield

      -=<[END]>=-

       
      • LD Landis
        LD Landis
        2006-12-05

        Hi,

          Oops!  Make that, for # in all runlevels for GT.M to run:

          # cd /etc/rc#.d
          # ln -s ../init.d/exec-shield S09exec-shield

        Cheers,
          --ldl

        -=<[END]>=-

         
    • LD Landis
      LD Landis
      2006-12-05

      Rob,

        In a similar way to the exec-shield note, you can add a K##gtm-shutdown
        (See RE: Signal 11 errors in Ubuntu Linux | ldl | 2006-12-05 21:41)
        script in /etc/init.d, which on a 'stop' argument does the GT.M
          mupip rundown -region "*"

        The K* scripts are run in order, so pick a place in the /etc/rd#.d
        for the rundown, and when shutdown(8) is run, so are he K* scripts for
        the runlevel you are in.

        I would recommend putting the link to rundown GT.M in for all runlevels,
        specifically rc0.d/ and rc6.d/ (halt and reboot, respectively).

        Note: conventionally I would expect to see GT.M in runlevels 3 and 5,
        possibly 2.  Since each site has its own conventions... you'll need to
        do a bit of investigation.  e.g. $ grep initdefault /etc/inittab

        On an AIX box I support, runlevel 2 is the default:
        $ grep initdefault /etc/inittab
        : Note - initdefault and sysinit should be the first and second entry.
        init:2:initdefault:

        On a typical Linux box, runlevel 3 is the default:
        $ grep initdefault /etc/inittab
        #   0 - halt (Do NOT set initdefault to this)
        #   6 - reboot (Do NOT set initdefault to this)
        id:3:initdefault:

        On my typical Linux boxes that have a display (most don't), runlevel 5:
        $ grep initdefault /etc/inittab
        #   0 - halt (Do NOT set initdefault to this)
        #   6 - reboot (Do NOT set initdefault to this)
        id:5:initdefault:

        FWIW, runlevel 5 is generally runlevel 3 plus *DM(e.g. XDM, an X Windows login)
        and generally (historically):
        0 is halt.
        1 is single-user.
        2 is multi-user without general networked services (Runlevels 2-5 are multi-user).
        3 is multi-user with networked services sans X-Window *DM (e.g. XDM, NDM, etc)
        4 is multi-user -- but generally not used
        5 is multi-user with networked services an an X-Window login server (e.g. XDM)
        6 is reboot.

        NOTE: To state (hopefully) the obvious, it is NOT necessary (nor desireable) to
        have a K*exec-shield in any of the /etc/rc#.d/ directories... The system is going
        away... who cares if GT.M can run there or not... only matters on startup.

      Cheers,
        --ldl

      -=<[END]>=-

       
    • robtweed
      robtweed
      2006-12-08

      Thanks for all this info.  Actually I've found that provided you use shutdown -h to close down the VM, I've not seen any problems with GTM restarting correctly.  I think I've figured out the reasons for the signal 11s I've otherwise seen and they're nothing to do with the shutdown issue.

      As someone relatively new to GT.M but with more years of experience with other MUMPS environments than I'd like to admit, I would like to make the comment that the sheer complexity of some of the things you have to do in order to get GT.M working is very daunting if either a) you've been used to the cosetted world of the "traditional" MUMPS environment and/or b) you're not a complete Linux expert.  In particular it's the amount of low-level Linux expertise you seem to need that certainly nearly frightened me away, and I know would be enough to put off many others who would otherwise be very interested in GT.M as an Open Source alternative to the commercial offerings.  This latter issue has been one of the incentives I've had in developing our Virtual Appliance concept, which, as far as possible, buries the need for most people to understand these finer points of Linux, and instead gives them a system that works right out of the box.    The VM approach is therefore clearly one way that should encourage many more people to try out GT.M and discover what a great alternative it really is to the commercial products.

      However I'd also encourage the developers of GTM to seriously consider automating a lot more of the installation and configuration steps with scripts, macros, wizards etc.