[archive] Thin Client with USE_UNIX_SHELL fails on 'cat' and 'echo'

[Migrated content. Thread originally posted on 14 December 2007]

Has any one experienced this and can share their solution? Here is what I did to resolve it:

AcuConnect 7.2.1 running on unix (HP-UX in my case). Configuration parm USE_UNIX_SHELL set to TRUE, necessary to initialize user environment prior to database access, etc. Thin Client would terminate the connection request with no error information in trace log except for an error message from an stty command: "stty: : Not a typewriter".

Spent a lot of time trying to add logic to the login profiles to keep TC from executing stty commands without resolving the problem. After much trial and error, I figured out that 'cat' and 'echo' commands anywhere in the login process were the actual culprit, not 'stty'. Had to check & edit profile files: /etc/profile and in user's home directory .login, .profile, .env to wrap some logic to test for an interactive terminal session around any occurrance of 'cat' or 'echo' that would send output to the terminal. The logic I added was this simple test:

if [ -t 0 ]
then
... interactive terminal stuff ...
fi

Thin Client works now and the connection appears to have the same environment as if a direct login was done. So that solved the problem, but...

This was a real frustrating, time-wasting pain to figure out in the first place. If a unix admin or other user comes along some time in the future and decides to edit one of those login files to 'echo' so much as a blank line to the screen, the Thin Client will stop working. And they will have no idea why.

I've scanned the AcuCorp/MicroFocus website, knowledgebases, release documentation, Google searches, etc. and found nothing related to this. I did open a ticket with the support line and the final result was that they confirmed that TC does have an issue with 'cat' and it should be avoided, and that there wasn't anything you could do to make the TC run any differently. Support did a great job researching this for me. I'm just really surprised that such a common cause, like 'cat' or 'echo' in a login profile, is still an issue for the Thin Client at version 7.2.1.

Has anyone else run into this issue? How did you resolve it? Do you know of another solution besides what I came up with? Is there any way to make the Thin Client ignore unix commands that display to the screen?:confused:

Thanks
~Dan

We changed this (in /etc/profile):

# Be sure that VUE does not invoke tty commands

if [ ! "$VUE" ]; then

To this:

# Be sure that VUE does not invoke tty commands

if [ ! "$VUE" ] && [ "$SHELL" != "/usr/local/bin/ableusersh" ]; then # the ableusersh clause was added by CASE/RG on 06 June 2006


And then we made /usr/local/bin/ableusersh a soft link to /usr/bin/sh.

$ ls -l /usr/local/bin/ableusersh
lrwxr-xr-x 1 root sys 11 Jun 20 2007 /usr/local/bin/ableusersh -> /usr/bin/sh
Then we made the UNIX user the Thin Client session "runs as" have a login shell of /usr/local/bin/ableusersh, which the script can detect with a reference to $SHELL.

This will end up making /etc/profile skip all of the copyright, message of the day, mail check, etc., which helps remove useless overhead that also has the side-effect you mentioned - but only for UNIX users with a login shell of /usr/local/bin/ableusersh.

This doesn't completely solve your problem of output to stdout before runcbl starts, but just shows how we supressed output from /etc/profile.

Note that you are going to have much bigger problems around the time you try to start the 17th simultaneous session if your shell is /usr/bin/sh. If it's a idifferent shell, keep reading anyway, because your problem will occur at a different number of users. This problem isn't just an HP-UX problem, but is a problem with all shells when USE_UNIX_SHELL=TRUE is in effect on all systems where that makes any sense (HP-UX, Linux, Solaris, MPE, etc.).

/usr/bin/sh always closes a group of file descriptors (from around 25, if I remember correctly). The way acurcl passes the open socket (from the thin client on the desktop), it just passes it in the FD it got the socket on, which, after about 16 sessions, end up being in FD 25, thus, the symptom will be that the socket connection back to the client is lost.

All UNIX shells have some range of reserved FDs that they use for their own use and must be avoided.

The issue here is that acurcl gets the socket, sets and environment variable with the FD of the socket (for runcbl), forks, the child execs the shell, the shell closes FD 25 to 250 something, the child (shell) execs runcbl to run your program which gets the environment variable and tries to talk to the Thin Client (but the socket was just closed by the shell!).

Our work-around is to have yet another "shell" in between acurcl and /usr/bin/sh. That "shell" just gets the USE_SOCKET environment variable, if the FD is greater than 9, it dupes it starting at 3 (which was already closed by acurcl in the child after the fork and before the exec of our shell) which ends up with a copy of the socket FD on 3 (or the lowest available FD >= 3), closes the original FD, re-writes the USE_SOCKET environment variable with the new socket FD then execs our /usr/local/bin/ableusersh (soft link to /usr/bin/sh).

Voila! Problem "solved".

Here's the source to our shell (we call it a "shim"), written in C (I apologize for the lack of indenting forced by the forum software):

/*
@(#) file: source/ableusershshim.c
@(#) title: ABLE User Shell Shim
@(#) remarks: CASE-developed
@(#) copyright: Copyright (c) 2007-2007, Computer And Software Enterprises, Inc.
@(#) author: $Author: rick $
@(#) date: $Date: 2007-06-21 16:52:12 -0700 (Thu, 21 Jun 2007) $
@(#) id: $Id: ableusershshim.c 731 2007-06-21 23:52:12Z rick $
@(#) rev: $Rev: 731 $
@(#) url: $URL: svn://abrepos/able/branches/aug-enh012/source/ableusershshim.c $

Modification History:

Date Document # Description
-------- ---------- -------------------------------------------------------
06/21/07 ACB/SUP180 created as a work-around for case# 49778 (RG)
06/21/07 ACB/SUP180 Q/A for ACB/SUP180 (DO)

*/

#include
#include

extern int main(int argc, char **argv, char **envp)
{

const char *sccs_file_tag = "\\100(#) file: object/ableusershshim";
const char *sccs_title_tag = "\\100(#) title: ABLE User Shell Shim Object";
const char *sccs_copyright_tag = "\\100(#) copyright: Copyright (c) 2007-2007, Computer And Software Enterprises, Inc.";
const char *sccs_author_tag = "\\100(#) author: $Author: rick $";
const char *sccs_date_tag = "\\100(#) date: $Date: 2007-06-21 16:52:12 -0700 (Thu, 21 Jun 2007) $";
const char *sccs_id_tag = "\\100(#) id: $Id: ableusershshim.c 731 2007-06-21 23:52:12Z rick $";
const char *sccs_rev_tag = "\\100(#) rev: $Rev: 731 $";
const char *sccs_url_tag = "\\100(#) url: $URL: svn://abrepos/able/branches/aug-enh012/source/ableusershshim.c $";

int fd = 0;
int fd2 = 0;
int i;
const char *name = "USE_SOCKET";
char *value;
char *value2[13];

value = getenv(name);
sscanf(value, "%d", &fd);
if (fd > 9)
{
fd2 = dup2(fd, 3);
if (fd2 == -1)
{
printf("dup2() failed; errno = %d\\n", errno);
exit(1);
}
if (fd2 > 9)
{
printf("dup2() returned an fd > 9; fd = %d\\n", fd2);
exit(2);
}
close(fd);
sprintf(*value2, "USE_SOCKET=%d", fd2);
putenv(*value2);
}
execve("/usr/local/bin/ableusersh", argv, envp);
printf("Couldn't exec /usr/local/bin/ableusersh; errno = %d\\n", errno);
exit(3);
}

Compile this then make the shell for the UNIX user that the Thin Client session runs as be "/usr/local/bin/ableusershshim".

Any questions? I check here once in a while so I'll add something to prompt me to check back around Friday the 21st.

You are welcome to use the code provided above at your own risk.

If you'd like to put a little pressure on Acucorp to fix this problem, try referring them to our case# 49778.

And now that I look at both issues together, I see that my "shim" could have set VUE in addition to re-writing USE_SOCKET and I could avoid modifying /etc/profile (probably a better idea).

Acurcl should just do the same "dup2" that I do and we wouldn't have the second problem on any UNIX systems.

Rick Gilligan
Sr. Software Specialist
Computer And Software Enterprises, Inc.

[Migrated content. Thread originally posted on 14 December 2007]

Has any one experienced this and can share their solution? Here is what I did to resolve it:

AcuConnect 7.2.1 running on unix (HP-UX in my case). Configuration parm USE_UNIX_SHELL set to TRUE, necessary to initialize user environment prior to database access, etc. Thin Client would terminate the connection request with no error information in trace log except for an error message from an stty command: "stty: : Not a typewriter".

Spent a lot of time trying to add logic to the login profiles to keep TC from executing stty commands without resolving the problem. After much trial and error, I figured out that 'cat' and 'echo' commands anywhere in the login process were the actual culprit, not 'stty'. Had to check & edit profile files: /etc/profile and in user's home directory .login, .profile, .env to wrap some logic to test for an interactive terminal session around any occurrance of 'cat' or 'echo' that would send output to the terminal. The logic I added was this simple test:

if [ -t 0 ]
then
... interactive terminal stuff ...
fi

Thin Client works now and the connection appears to have the same environment as if a direct login was done. So that solved the problem, but...

This was a real frustrating, time-wasting pain to figure out in the first place. If a unix admin or other user comes along some time in the future and decides to edit one of those login files to 'echo' so much as a blank line to the screen, the Thin Client will stop working. And they will have no idea why.

I've scanned the AcuCorp/MicroFocus website, knowledgebases, release documentation, Google searches, etc. and found nothing related to this. I did open a ticket with the support line and the final result was that they confirmed that TC does have an issue with 'cat' and it should be avoided, and that there wasn't anything you could do to make the TC run any differently. Support did a great job researching this for me. I'm just really surprised that such a common cause, like 'cat' or 'echo' in a login profile, is still an issue for the Thin Client at version 7.2.1.

Has anyone else run into this issue? How did you resolve it? Do you know of another solution besides what I came up with? Is there any way to make the Thin Client ignore unix commands that display to the screen?:confused:

Thanks
~Dan

Oh, if you continue to have problems that are difficult to trace, install "tusc" on HP-UX and try attaching to acurcl and tracing, following forks.


To trace an already running process, follow its new descendants, display all exec arguments, display environment variables and display pids with verbose detail:

bash-3.2# ps -ef | grep acurcl | grep -v grep
root 26000 1 0 Nov 6 ? 1:00 /opt/acucorp/720/bin/acurcl -start -t 7 e /var/adm/acurcl.log1
bash-3.2# tusc -a -e -f -p -vvv 26000
( Attached to process 26000 ("/opt/acucorp/720/bin/acurcl -start -t 7 e /var/adm/acurcl.log1") [32-bit] )
[26000] select(4, 0x7fffe960, 0x7fffe9e0, NULL, 0x7fffe950) .................................................. [sleeping]
nfds: 4
readfds: 3
writefds: EMPTY
errorfds: NULL
timeout.tv_sec: 3
timeout.tv_usec: 0

Rick

[Migrated content. Thread originally posted on 14 December 2007]

Has any one experienced this and can share their solution? Here is what I did to resolve it:

AcuConnect 7.2.1 running on unix (HP-UX in my case). Configuration parm USE_UNIX_SHELL set to TRUE, necessary to initialize user environment prior to database access, etc. Thin Client would terminate the connection request with no error information in trace log except for an error message from an stty command: "stty: : Not a typewriter".

Spent a lot of time trying to add logic to the login profiles to keep TC from executing stty commands without resolving the problem. After much trial and error, I figured out that 'cat' and 'echo' commands anywhere in the login process were the actual culprit, not 'stty'. Had to check & edit profile files: /etc/profile and in user's home directory .login, .profile, .env to wrap some logic to test for an interactive terminal session around any occurrance of 'cat' or 'echo' that would send output to the terminal. The logic I added was this simple test:

if [ -t 0 ]
then
... interactive terminal stuff ...
fi

Thin Client works now and the connection appears to have the same environment as if a direct login was done. So that solved the problem, but...

This was a real frustrating, time-wasting pain to figure out in the first place. If a unix admin or other user comes along some time in the future and decides to edit one of those login files to 'echo' so much as a blank line to the screen, the Thin Client will stop working. And they will have no idea why.

I've scanned the AcuCorp/MicroFocus website, knowledgebases, release documentation, Google searches, etc. and found nothing related to this. I did open a ticket with the support line and the final result was that they confirmed that TC does have an issue with 'cat' and it should be avoided, and that there wasn't anything you could do to make the TC run any differently. Support did a great job researching this for me. I'm just really surprised that such a common cause, like 'cat' or 'echo' in a login profile, is still an issue for the Thin Client at version 7.2.1.

Has anyone else run into this issue? How did you resolve it? Do you know of another solution besides what I came up with? Is there any way to make the Thin Client ignore unix commands that display to the screen?:confused:

Thanks
~Dan

Oh, if you continue to have problems that are difficult to trace, install "tusc" on HP-UX and try attaching to acurcl and tracing, following forks.


To trace an already running process, follow its new descendants, display all exec arguments, display environment variables and display pids with verbose detail:

bash-3.2# ps -ef | grep acurcl | grep -v grep
root 26000 1 0 Nov 6 ? 1:00 /opt/acucorp/720/bin/acurcl -start -t 7 e /var/adm/acurcl.log1
bash-3.2# tusc -a -e -f -p -vvv 26000
( Attached to process 26000 ("/opt/acucorp/720/bin/acurcl -start -t 7 e /var/adm/acurcl.log1") [32-bit] )
[26000] select(4, 0x7fffe960, 0x7fffe9e0, NULL, 0x7fffe950) .................................................. [sleeping]
nfds: 4
readfds: 3
writefds: EMPTY
errorfds: NULL
timeout.tv_sec: 3
timeout.tv_usec: 0

Rick