/etc/profile.d script interfering with a service starting, and considerably delaying ssh availability after reboot

Question

I have created a script in /etc/profile.d (centos6), not related to puppet in any way, instead it just copy's some files to a users dir. Somehow, on a puppet enterprise master server, this script is interfering with the service pe-postgresql, and causing the server to delay on boot, and will not let that service run.

This profile script has a feature that prompts a user on login and asks them if they want to install (y,n), if one of its files aren't found. I suspect this is happening in the background to something when a puppet service is starting somewhere, causing that service to fail.

#/etc/profile.d/custom.sh
if [ ! f ~/.custom ]; then
    logPrompted;
    while true; do
        read -p "Do you want to install?)" yn
        case $yn in
         [Yy]* )
           installCustom;
           break;;
         [Nn]* )
           logOptedOut;
           break;;
         * ) echo "Please enter y or n!";;
        esac
    done
fi

As soon as move the file out of /etc/profile.d, the problems stop. E.g. sudo service pe-postgresql start fails every time when that script is in place.

When I look at puppet users cat /etc/passwd | grep pe- I can verify that all of them are nologin.

There is either something im missing here, or another puppet service user that I'm missing. which is possibly interactive.

I added logging on each run to see when its ran(logPrompted), before the question, by reporting $(whoami), hoping to uncover the hidden user, and on the log i do indeed see pe-postgres being logged each time "I" try to restart the service, but this is not consistent.

looking at /etc/passwd this user is pe-postgres:x:492:493:Puppet Enterprise PostgreSQL Server:/opt/puppet/var/lib/pgsql:/sbin/nologin

Im trying to figure out how i can avoid this user, or any nologin user to interact with this profile script.

Is there something I might need to add to the beginning of a profile.d script to safeguard it from these kinds of things?

Answer 1

Prompts only make sense when the shell is interactive. (You wouldn't want them to interfere with e.g. SFTP connections...) To check for interactivity, you have two options:

• Test whether $- contains the letter i.

  case $- in
    *i*) <do your prompts>;;
    *) return;;
  esac
  

  Or:

  if ! case $- in *i*) false; esac; then
      <do your prompting>
  fi
  

• Use [ -t 0 ] to test whether stdin (file descriptor #0) is a terminal:

  if [ ! -t 0 ]; then
      return
  fi
  

  Or:

  if test -t 0; then
      <do prompts here>
  fi
  

(Since your script is "sourced" by a parent script, calling return outside functions is allowed and will return to the parent script. That allows you to avoid an extra level of indentation.)

The 2nd method (checking stdin) doesn't actually test interactivity – for example, sh -l -c "some command" would still pass the test when being run through a terminal. But it still works in many cases, because services and SFTP connections do not have a terminal allocated.