No prompt!

UNIX Solaris
1

We have a Solaris 10 machine.
Today a weird issue happened.

After login remotely via ssh, the motd appeared BUT
there was no prompt!

The prompt only appears after pressing Ctrl+d or Ctrl+c.
Strange behaviour.

I have checked /etc/profile and own user .profile, there is no anamoly.

When I typed who -u, the tty is displayed as syscon instead of pts/..

Can anyone explain this behaviour or provide a solution?

Thanks.

2

Double check that. It looks like there is a process reading stdin from your description. What says, from another terminal:

ptree $(pgrep sshd)
3

Here is the output,

$ for i in `pgrep sshd`
> do ptree $i
> done
8688 /usr/lib/ssh/sshd
 10546 /usr/lib/ssh/sshd
  10549 /usr/lib/ssh/sshd
   10551 -sh
    10563 ptree 10546
8688 /usr/lib/ssh/sshd
  10546 /usr/lib/ssh/sshd
   10549 /usr/lib/ssh/sshd
    10551 -sh
     10564 ptree 8688
8688 /usr/lib/ssh/sshd
   10546 /usr/lib/ssh/sshd
     10549 /usr/lib/ssh/sshd
      10551 -sh
        10565 ptree 10549
sunxxx 10551 10549   0 02:35:12 syscon      0:00 -sh
sunxxx 10569 10568   0 02:38:09 syscon      0:00 ps -ef
sunxxx 10549 10546   0 02:35:12 ?           0:00 /usr/lib/ssh/sshd
sunxxx 10568 10551   0 02:38:09 syscon      0:00 grep sunxxx

What is syscon?

When I start a duplicate session, it logs in perfectly. :confused:

What could be the issue?

4

Is it the same case if you were to use a different UID to ssh?

5

Yes. It happens for all user ids.

6

You can add "set -x" at the beginning of /etc/profile and see where the login scripts hangs.

7

Thanks to jlliagre for the assistance.

I have inserted set -vx to debug.
And found it hangs at a script line which is executing grep.
The pattern is passed a value obtained from the command logname

Unfortunately logname doesn't return a value to the variable,
so it's stuck at the line grep $variable /file.

But why doesn't the command logname return a value?
I have executed in command prompt and there is no value at all!

How to use truss command to check logname execution?

8

an FYI for others. this behavior happened exactly as described above regarding several of my boxes. i ended up finding out that the file /etc/issue had thousands of lines of carriage returns. obviously removing the file and creating a new one resolve the issue. fun times trying to figure that little gem out :slight_smile:

9

Another different cause of similar behavior can be the /usr/sbin/quota command which is part of the /etc/profile script taking an very long time to proceed.

10

Thank you for the feedback.

I have checked and found neither /etc/issue exist nor quota has been set in this server.

I have executed "truss -a logname" and found that there is some difference when compared with another server's output.

Server with logname returning null value

Server with logname returning value

The problem server doesn't proceed beyond /dev/syscon..

Any input would be appreciated!

11

Sure. These were examples of different root causes of similar issue. Yours has already been found and it is just the login script used is bogus. Logname isn't required to return a value so the script should take that into account.

You might test logname status and use a different approach to get the username like this:

logname=`logname`
logname=${logname:-`/usr/xpg4/bin/id -un`}

or simply use

/usr/xpg4/bin/id -un

in the first place.

12

Well, if logname isn't required, how does the environment variable
LOGNAME get the value?

We have another server with similar configuration ( replica ) which works fine.There, it does return a value.

Anyways, these are my unresolved doubts.
I would try out your workaround, jlliagre :rolleyes:.
Thank you for your invaluable assistance.:b: