Hi! On Sun, Jun 19, 2005 at 12:52:12AM +0200, Nicolas François wrote: > I can also reproduce it.
Me too, except for "no characters echoed" symptom. > It is caused by the new setting of CLOSE_SESSIONS > to yes in /etc/login.defs. Excellent analysis. I came to conclusion that suspend returns control to its parent process, which is "su" in the below examples: 4957 ? S 0:00 \_ xterm 4958 pts/2 Ss 0:00 \_ bash 4961 pts/2 S 0:00 \_ su - 4963 pts/2 S 0:00 \_ -su 4969 pts/2 R+ 0:00 \_ ps -A f In the above example `su -` was used, and therefore child bash is called "-su" because it's treated like login shell by "dashed su". 4941 ? S 0:00 \_ xterm 4942 pts/1 Ss 0:00 | \_ bash 5042 pts/1 S 0:00 | \_ su 5044 pts/1 S 0:00 | \_ bash 5047 pts/1 R+ 0:00 | \_ ps -A f This is for `su` without dash -- here you clearly see where is child bash located WRT parent _shell_. So, immediate parent of bash would be su and not parent bash. > To perform CLOSE_SESSIONS, a fork is needed, and when the shell is > suspended, the whole process is not completely suspended and thus the > previous shell (used to su) do not get the focus. About fork you are right, but for the other I seem to not understand your point. > So, setting CLOSE_SESSIONS to no will solve this issue (but won't close > this bug). Yes, here we have: 4941 ? S 0:01 \_ xterm 4942 pts/1 Ss 0:00 | \_ bash 5063 pts/1 S 0:00 | \_ bash 5067 pts/1 R+ 0:00 | \_ ps -A f Here you can see that parent and child shells don't have intermediate "su" process between them. > I still don't know how to fix this issue with CLOSE_SESSIONS set to yes. Wontfix? > I noted that if "su -" is used, then bash reports: > suspend: cannot suspend a login shell > That may be an hint. IMHO, this is just a warning that user will be simply locked on that particular terminal, because login shell usually is SHLVL==1, i.e. don't have a parent shell. -- WBR, xrgtn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]