"Cannot start job control" from ksh ... what does this mean?

[A. Daniel King_1]

Hi, folks.

I've got several processes I'd like to run in a loop like:

echo command | su - user1
echo command | su - user2
echo command | su - user3
...

The loop I've got seems to work. However, I see that, when I put this in the background, I get the error message, "Cannot start job control".

echo command | su - user1 &
echo command | su - user2 &
echo command | su - user3 &
...

The first item runs, but the rest fail.

Ideas?

Thanks in advance.

[James R. Ferguson]

Hi Daniel:

Yes, I would expect them to fail in the background. By employing the '-' option with 'su' you are causing teh suer's $HOME/.profile to be sourced (read). The problem is that most profile's contain 'stty' and 'tset' commands that expect stdin to be a terminal. Thus the process hangs for SIGTTIN when invoked in the background.

If you wish to use the 'su' then eliminate the '-' option. Merely make sure any environmental variables from the .profile are included otherwise. This will work:

# su user -c whoami &

...but this will not:

# su - user -c whoami &

Regards!

...JRF...

[A. Daniel King_1]

Hi, James.

Yes, I do really want to source /etc/profile and the user's .profile, etc.

This is somewhat messy, but there are some processes which are best started from the menu, into which our users are locked.

Do you have other ideas?

[James R. Ferguson]

Hi (again) Daniel:

If you really want to continue to source the user's profile, then modify that profile to conditionally execute 'tset' and 'stty' commands:

# if [ -t 0 ]; then
...stty #...interactive stuff...

Regards!

...JRF...

[A. Clay Stephenson · Accepted solution]

No, you really don't want to source the .profile because that is your problem. The .profiles contain commands like stty, tabs, and tset which depend upon an interactive environment. You could edit each .profile and surround each stty, tabs, tsets, etc. with:

if [[ -t 0 ]]
then
tset ..
tabs
fi

BUT a MUCH cleaner method is to pull all the environment variable junk out of the .profiles and put them in a standard location. e.g. /usr/local/bin/myenv.sh. Make sure that this script does notcontain exit or return statements. Next, put /usr/local/bin/myenv.sh in BOTH the user's .profile and your scripts using the "."
method.

e.g.
. /usr/local/bin/myenv.sh.

You are actually compounding your problem by echo'ing the commands rather than using the su user -c command syntax. In your case, stdin is absolutely guaranteed not to be a terminal device because it is a pipe.

[Dave La Mar]

A.Daniel-
Clay set me straight on this in the past.
In our case, we justed added the required environment variable to the script we were executing.
But as Clay noted, his suggestion makes the function reuseable.

Best of luck.

Regards,
dl

[A. Daniel King_1]

In the ideal world, Clay, you would be right.

I am working toward this type of situation. I am actively untangling a mess of environments (yes, plural), which are recursively (i.e., PATH=$PATH:/abc) called, starting with /etc/profile.

Once clean, I will be happier. For the mean time, I am using a pipe into "su -"

Thanks.