Shell ...killed ?

[wobo]

Usually I do root tasks in a konsole window. I become root by using 'su -'. When work is finished I do Ctrl-d to exit from the root shell. This looks like

Code: Select all

[root@marvin-2 etc] # exit
[wobo@marvin-2 wobo] $

Since todays updates when I do Ctrl-d I see

Code: Select all

[root@marvin-2 etc] # exit
... killed
[wobo@marvin-2 wobo] $

Which process is "...killed"? Is this "...killed" just an enhancement to tell me that the shell for root was killed? In the output of 'ps aux' I only see (last 3 processes, all owned by root):
su -
-bash
ps aux

Which brings another question: Why is the process 'su -' owned by root while it was started by the user?

[jaywalker]

What took you so long? I've been seeing that for weeks. Can't say for sure when it first popped up. Have you also noticed that it takes a second or more to go back to your user shell?

Having said that, I just tried it to su root and then su back to myself, then hit CTRL-D twice and it was instant!

[wobo]

Well, I've been doing daily updates for at least 5 or 6 days (always with urpmi, so I had to face the su-dance each day. Today it was the first time this "delay" showed. I can not explain why this was not visible before.
New: now it does not show the "...killed" line, it also takes a 2 - 3 seconds and it clears the screen - which is annoying because sometimes I want to scroll up earlier output in that shell.

I just tried it to su root and then su back to myself, then hit CTRL-D twice and it was instant

Can't confirm this.
I su'd to root, then from there su'd to wobo. Hit Ctr-d and was back to root in an instant, another Ctrl-d (to get back to the original shell) showed the ...killed, took 2 seconds and cleared the screen, landing at the user prompt.

This turned up today at all of my 3 Cauldron systems.

[jaywalker]

I use lxterminal under lxde rather than your konsole and kde(?) so it's not just the way a particular terminal emulator does its thing. Just checked on a Beta2 system up-to-date as of last Friday and it still shows the killed message and the delay.

The only thing I can think of which may have changed the way the shell manages its processes is the usual suspect; systemd was massively updated and the recent dalliance with information-free kernel logs has been abandoned (for good? hope so), but nothing else in my list (of as yet un-applied updates) looks even remotely relevant.

[martinw]

So it's not just me...

I've seen this for some time - but only when I've logged into another machine via ssh. If I use 'su' on the machine I'm sitting at, I don't get the delay.

If I use 'su -f' then I don't get the delay either, so it must be something caused by one of the shell startup scripts.

[junk_no_spam]

So it's not just me...

I've seen this for some time - but only when I've logged into another machine via ssh.

Yes I see that once in awhile.

if I use 'su' on the machine I'm sitting at, I don't get the delay.
If I use 'su -f' then I don't get the delay either, so it must be something caused by one of the shell startup scripts.

I have a xroot script which basically launches xterm -e -fg white -bg darkBlue "sudo su - root" &
A new xterm pops up at the root prompt.
I hit Ctrl d and it disappears without problem.

[jaywalker]

This turned up today at all of my 3 Cauldron systems.

Just for clarity let me summarise what I think we two (+2) are saying;

Code: Select all

Period                           Person                "...killed " delay?       comment
up to (say) Friday 30th Mar         me                      yes
up to (say) Friday 30th Mar         wobo                     no
up to (say) Friday 30th Mar         martinw                  yes             only remote via ssh
up to (say) Friday 30th Mar         junk_no_spam             yes             only remote via ssh
Monday 2nd April                   me                       no
Monday 2nd April                   wobo                     yes
Monday 2nd April                   martinw                  yes              only remote via ssh
Monday 2nd April                   junk_no_spam             yes             only remote via ssh


[martinw]

And just to add to my confusion, after trying and failing to identify which startup file was causing the problem, I now find the 'su -f' fix isn't working any more...

[martinw]

Which brings another question: Why is the process 'su -' owned by root while it was started by the user?

I guess 'su' calls 'setuid' to change the effective user ID of the process.

[jaywalker]

Yes, the suid bit is set on /bin/su

[junk_no_spam]

Just for clarity let me summarise what I think we two (+2) are saying;

Not me. Always have/had an occasional ssh log out hang. Mostly when I ssh same machine more than once.
Understandably since my .bash_logout has a few lines of code.

Only a very, very few hangs logging out of current machine.

Do keep in mind we all have a hardware component here.

My "Production" machine is a fast 4 cpu box, my mtv box is a fast 2 cpu, and my test bed is an old not so fast single cpu box.
You also have to keep in mind the log out process goes to a low priority while your current background process could be jumping in front of the log out process, you know the Nepomuk, Akonadi, Strigi indexing bs.

It is interesting to see how long it takes kde to finally let a kde user process finish cleanup.

[jaywalker]

, you know the Nepomuk, Akonadi, Strigi indexing bs.

Ummm, Nope. You got me there. I have no idea what you are talking about. I don't think I have ever had any of that on my Cauldron test systems. Am I missing something exciting and stimulating?

OK, I know it's a KDE thing. When I am really pushing my system it doesn't have time to spare for something as pretty as KDE.

[martinw]

I'm seeing this behaviour

• on a remote machine that doesn't have a GUI or any other heavyweight tasks running
• using 'su', not 'su -' (so login/logout scripts are not being executed)
• using csh, not bash

Still can't find the cause!