Those error messages look like they come from the C shell, tcsh.  Have you changed the system shell to tcsh, or else is rdt's shell set to tcsh?  Just trying to understand how to reproduce the problem myself.

 > is rdt's shell set to tcsh? 

Yes.  The problem is clearly in lines 54-61, which are executed as ${USER}. 
Earlier versions were shell-agnostic.

OK, I see it. Thanks.

Please  privide me the script we  are having same problem we have installed SAP and users will be creating under c shell by the installation.vnc server has been configured ,it runs perfectly with one user (i.e iam able to start the vncserver script without the error)but when it is configured for other  user that belongs to c shell it is giving me error

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

*** Bug 1030747 has been marked as a duplicate of this bug. ***

Created attachment 825796 [details]
just let vncserver fail if no passwd file

I've been using this patch for a while now.  Copied from bug 1030747 that I submitted before seeing this bug.

I just made up this patch before seeing this bug

[root@raoultella init.d]# diff vncserver.orig vncserver -ubB
--- vncserver.orig	2014-02-05 10:52:53.449368175 +0100
+++ vncserver	2014-02-05 10:50:56.263368429 +0100
@@ -50,7 +50,7 @@
 	DISP="${display%%:*}"
 	USER="${display##*:}"
 	VNCUSERARGS="${VNCSERVERARGS[${DISP}]}"
-        runuser -l ${USER} -c \
+        runuser -l ${USER} -s /bin/bash -c \
 		"cd ~${USER} &&
 		 if [ -r .vnc/passwd ]; then
 			 vncserver :${DISP} ${VNCUSERARGS}


Tobias

(In reply to Tobias Oed from comment #10)
> I just made up this patch before seeing this bug
> 
> [root@raoultella init.d]# diff vncserver.orig vncserver -ubB
> --- vncserver.orig	2014-02-05 10:52:53.449368175 +0100
> +++ vncserver	2014-02-05 10:50:56.263368429 +0100
> @@ -50,7 +50,7 @@
>  	DISP="${display%%:*}"
>  	USER="${display##*:}"
>  	VNCUSERARGS="${VNCSERVERARGS[${DISP}]}"
> -        runuser -l ${USER} -c \
> +        runuser -l ${USER} -s /bin/bash -c \
>  		"cd ~${USER} &&
>  		 if [ -r .vnc/passwd ]; then
>  			 vncserver :${DISP} ${VNCUSERARGS}
> 
> 
> Tobias

That forces your vnc environment to have SHELL set to /bin/bash which may not be desirable (usually isn't if your default shell is /bin/csh, for instance).

(In reply to John Hein from comment #11)
> (In reply to Tobias Oed from comment #10)
> > I just made up this patch before seeing this bug
> > 
> > [root@raoultella init.d]# diff vncserver.orig vncserver -ubB
> > --- vncserver.orig	2014-02-05 10:52:53.449368175 +0100
> > +++ vncserver	2014-02-05 10:50:56.263368429 +0100
> > @@ -50,7 +50,7 @@
> >  	DISP="${display%%:*}"
> >  	USER="${display##*:}"
> >  	VNCUSERARGS="${VNCSERVERARGS[${DISP}]}"
> > -        runuser -l ${USER} -c \
> > +        runuser -l ${USER} -s /bin/bash -c \
> >  		"cd ~${USER} &&
> >  		 if [ -r .vnc/passwd ]; then
> >  			 vncserver :${DISP} ${VNCUSERARGS}
> > 
> > 
> > Tobias
> 
> That forces your vnc environment to have SHELL set to /bin/bash which may
> not be desirable (usually isn't if your default shell is /bin/csh, for
> instance).

We need to assure, that the command supplied after -c is properly executed. It has nothing to do with user's or root's shell preferences (-s ${SHELL}), IMHO it must be the shell which the command is written in. So if #!/bin/bash is the hashbang of /etc/init.d/vncserver, I see nothing wrong with enforcing /bin/bash as a shell for runuser command as well.

Another approach would be to use command without any shell specific constructions.

It's the if ... then ... else that's the problem.  Just test for non-existence of the passwd file separately:

 runuser -l ${USER} -c \
    "cd ~${USER} && [ ! -r .vnc/passwd ] && (echo ; echo VNC password for user ${USER} is not configured; exit 1)"
 runuser -l ${USER} -c \
                "cd ~${USER} && [ -r .vnc/passwd ] && vncserver :${DISP} ${VNCUSERARGS}"

Created attachment 882348 [details]
Here is the change I plan to make

Created attachment 882362 [details]
Here is the change I plan to make (sorry, missed a bit in the last one)

Warning and apologies - The comment herein is slightly off the main topic for this bug.  The following is just in response to a comment in this thread that will hopefully clarify some apparent misconceptions:

@Filip in comment 13.  I think you misunderstand the ramifications of the -s and what runuser does.  You can use runuser to execute any shell script from any shell you specify with -s.

example:

cat > somecsh << eof
#!/bin/csh -f
setenv FOO bar
printenv SHELL
printenv FOO
eof
chmod a+x somecsh

If you try to run this with bourne shell, it will fail of course:

sh somecsh
somecsh: line 2: setenv: command not found


But you can use runuser to execute that script with either -s /bin/csh or -s /bin/sh, and it will work fine.  Try it yourself:

sudo runuser -s /bin/csh -c ./somecsh joe_regular_user
/bin/csh
bar

sudo runuser -s /bin/sh -c ./somecsh joe_regular_user
/bin/sh
bar

The problem in this case is that you are starting a vnc session and all children inherit the SHELL environment variable.  So even if /etc/passwd specifies /bin/csh, any terminal window started under a vnc session that has inherited SHELL=/bin/sh will start /bin/sh as the shell.

That's why just using -s /bin/sh fails to be an optimum solution.  It allows the bourne shell specific code in the init.d script to run, but causes undesirable side effects in the spawned vnc session (i.e., the inherited SHELL environment variable).

I've been running with the patch in comment 16 for a while now on a few systems.  It fixes the reported problem and I haven't noticed any regressions.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1412.html