[SOLVED] strace kdesu konqueror & > ./strace_kdesu (diagnosing failing kdesu)

GrapefruiTgirl · 08-08-2009, 07:09 AM

This is a continuation from Post 15 and Post 16 because it's becoming IMHO beyond the 'newbie' forum (at least, this strace is--

it's beyond me, that's for sure..)

First, an observation:

Code:

bash-3.1$ kdesu konqueror &
[1] 1562
bash-3.1$ ****

See the asterisks? Those are AFAICT supposed to be (or are) the ones shown when entering a root password into `kdesu`. While the count of asterisks in the kdesu dialog is correct, a failed kdesu leaves some asterisks in the console..

Now, strace I directed to a file, and ended up with a 208 Kib file, way too big to post. However, here's a few snippets: EDIT: snippets of this large output are useless; I've attached the file in case anyone wants to look at the whole thing: Attachment 1180

While there are hundreds of file not found errors, sometimes kdesu does work, and sometimes not

I did detect 'Segmentation Fault' returned in the console from kdesu, several times. The kdesu dialog *did* appear
but something segfaulted along the way, and returned the control to the console.

I'll look into .xsession-errors next and see if there's anything there.

GrapefruiTgirl · 08-08-2009, 08:46 AM

.xsession errors appears to deal (primarily) with the startup of the X session itself (starting xfce) but does not contain anything pertaining to apps started since that time.

99% of the file is just identical GTK-warnings about attempting to allocate a widget:

Code:

(xfce4-panel:1211): Gtk-WARNING **: gtk_widget_size_allocate(): \
attempt to allocate widget with width -3 and height 1

As suggested in the other thread, I'll try a stock kernel and see what happens.

Sasha

jschiwal · 08-08-2009, 09:58 AM

You might try checking if the cached libraries exist:

Code:

while read library; do   
   if [ -f $library ]; then echo -e "$library \tEXISTS";
                       else echo -e $library "\tDOESN'T EXIST";
   fi; done < <(/sbin/ldconfig -p  | sed 's/.* => //')

I would suggest checking if all of the directories listed in /etc/ld.so.conf actually exist. Remove any that don't. Then run "sudo /sbin/ldconfig" whether you deleted any lines or not. I don't have any attempts at looking in /usr/lib64/tls/ directory.

Yours:

Code:

sendto(9, "EXEC \"konqueror\" \"root\" \"\" \"DESKT"..., 71, 0, NULL, 0) = 71
recvfrom(9, "NO\n"..., 1023, 0, NULL, NULL) = 3

Mine:

Code:

sendto(9, "EXEC \"konqueror\" \"root\" \"\" \"DESK"..., 72, 0, NULL, 0) = 72
recvfrom(9, "OK\n", 1023, 0, NULL, NULL) = 3

GrapefruiTgirl · 08-08-2009, 10:50 AM

[QUOTE=jschiwal;3635822]

Code:

while read library; do   
   if [ -f $library ]; then echo -e "$library \tEXISTS";
                       else echo -e $library "\tDOESN'T EXIST";
   fi; done < <(/sbin/ldconfig -p  | sed 's/.* => //')

Jim, I'm having trouble making the script execute:

Code:

sh-3.1# while read library; do       if [ -f $library ]; then echo -e "$library \tEXISTS";                        else echo -e $library "\tDOESN'T EXIST";    fi; done < <(/sbin/ldconfig -p  | sed 's/.* => //')
sh: syntax error near unexpected token `<'

I tried entering line by line, and tried some little edits, to no avail.

However:

By removing the tail end of the code you gave:

Code:

 < <(/sbin/ldconfig -p  | sed 's/.* => //')

I can make the verification process work. But NONE of the 4 items in my ld.so.conf exist according to your script.
I'm going to manually reconf my ld.so.conf correctly and re-evaluate the whole situation.

Thanks Jim -- I think you're onto something here!

Sasha

GrapefruiTgirl · 08-08-2009, 10:29 PM

Well, my ld.so.conf file was kinda sketchy so I fixed it up. That didn't help the problem directly, but it DID make for less errors & file-not-founds in the strace output.

Rebooted, no change.

Reinstalled entire system, no change.

Currently, if I do `kdesu konqueror &` most of the time the following happens:

1) first time, nothing. it just quits or does nothing.
2) second time, kdesu dialog appears, but it won't accept my password the first time I enter it.
3) enter password second time, and konq starts.

NOTE: there are exceptions to the above; sometimes it still doesn't work, but usually after a while, and after running kdesu many times, it eventually seems to work reliably.

Next thing I'll try will be the stock kernel I guess.. But I still don't see how that can be causing this. Who knows though; maybe it is.

Sasha

OH -- PS: the /usr/lib64/tls directory is created/used by the nvidia driver.

jschiwal · 08-09-2009, 09:32 AM

Search your home directory for files owned by root. Include hidden files & directories in your search. Also look in /tmp for files and directories that should be owned by you. Before rebooting, log out and go to the single user init level (init level 2?) and clear out everything in /tmp.

Check the /var/log/messages the next time you have a problem with kdesu. Validate the package that supplies kdesu and the PAM files. Using kdesu, PAM uses xauth to exchange cookies.

I don't know why the problem would be intermittant. Is there a problem if you use sudo to launch a program? You may need to use xauth to give root an xauth cookie before trying.

xauth extract - :0.0 | sudo xauth merge -

PAM may be configured to do this automatically. There's a reason we don't have the "sux" command. Kind of miss that name!

GrapefruiTgirl · 08-09-2009, 09:57 AM

Quote:

Originally Posted by jschiwal

Search your home directory for files owned by root. Include hidden files & directories in your search.

Done. No results other than some junk in the Trash, which I deleted.

Quote:

Before rebooting, log out and go to the single user init level (init level 2?) and clear out everything in /tmp.

That'd be init level 1 on Slack, which I'll try before rebooting this time, and empty /tmp.

Quote:

Check the /var/log/messages the next time you have a problem with kdesu. Validate the package that supplies kdesu and the PAM files. Using kdesu, PAM uses xauth to exchange cookies.

Okies, I wasn't aware that PAM was in use at all here (Slack-current) as I am only REALLY familiar with Slack-11. I do see that it's installed, but thought I had toconfigure it to be in use (or maybe I need to configure it, period!) and I will investigate this further later on.

Quote:

I don't know why the problem would be intermittent.

Yeah, me neither

Quote:

Is there a problem if you use sudo to launch a program?

AFAIK, there's no sudo included with Slack by default. I just ran `which sudo` and `sudo hello` both with no sudo found.

Quote:

You may need to use xauth to give root an xauth cookie before trying.

xauth extract - :0.0 | sudo xauth merge -

That's a new one on me too. Never had to do such a thing on Slack 11, but further comments are welcome about that.

Quote:

PAM may be configured to do this automatically. There's a reason we don't have the "sux" command. Kind of miss that name!

Again, I'll look into PAM again after reboot & another test. BTW, I still haven't tried the default kernel, but (also again) I can't see the kernel being a problem, but it's getting near that time to try it anyhow...

Thanks again!! Going to init 1 now, empty /tmp, and reboot. Will update in a bit

Sasha

GrapefruiTgirl · 08-09-2009, 10:08 AM

Quote:

Originally Posted by GrapefruiTgirl

Thanks again!! Going to init 1 now, empty /tmp, and reboot. Will update in a bit

Sasha

WooooHooo!

Upon reboot & login, I immediately opened a konsole, ran `kdesu konqueror` and IT WORKED perfect the first time!

I closed it, tried `kdesu konqueror &` and again, worked perfect!

Must have been something in /tmp I guess

but what it was, and how/why it was how it was, I'll never know -- it's all `rm -Rf`'d

Thank you JS!

Sasha

PS - marking this [solved] but please feel free, anyone, to give more input, as I/we don't *really* know how the problem originated.

jdkaye · 08-09-2009, 11:58 AM

Quote:

Originally Posted by GrapefruiTgirl

PS - marking this [solved] but please feel free, anyone, to give more input, as I/we don't *really* know how the problem originated.

Cue somber, scary music. A deep voice intones, "Somethings we were not meant to know!"

Glad you sorted your problem.
cheers,
jdk

jschiwal · 08-09-2009, 07:01 PM

Sasha: I must confess that I am not familiar enough with Slackware. I should be. After all, Pat started his distribution as a Moorhead State University student, just across the river from where I live in Fargo, ND. An NDSU EEE student suggested the distro he used as a starting point. A friend from NDSU suggested the name Slackware. ( Interesting, that these suggestions both occurred at a party or a club. What is the lesson there? )

I don't know why the script didn't work. I started with the ldconf command, which listed the libraries in ld.so.cache. The output looks like:
libICE.so.6 (libc6,x86-64) => /usr/lib64/libICE.so.6
libICE.so (libc6,x86-64) => /usr/lib64/libICE.so

The sed command strips off the first two columns. I could have used the cut command to do the same.
I like the < <(....) notation. It looks neat. My favorite use is "mv -i /dir1/* /dir2/ < <(yes no)". Anyway it is similar to using backticks. At work, I use "comm -23 <(sort list1) <(sort list2)" a lot to discover items unique to list2 that are mpeg files that need to be deleted from adtec decoders. The comm command operates on sorted input.

AFAIK, Slackware support PAM now. As PAM is used in Linux/Solaris/BSD I think it is around to stay. Slackware reminds me of an early Mustang or Maveric with manual transmission. ( pre computers & emission controls ) As and end user you can work under the hood, and understand how it works. (or do you use the word bonnet?)

You may have had a stale pid file. This can prevent a program from starting, because of an existing pid file, makes it think it already is. Also if you use kdesu and run kde apps, you can have some files in you home directory or in /tmp/ be owned by root. Especially config files and log files. This can deny a program access to it's own configuration file. That's why I had you look for root owned files in your home directory.

Running "sudo /sbin/depmod -a" and "sudo /sbin/ldconfig" can sometimes clear up kernel module and library related problems due to an interrupted installation, or a mistake by the packager. These two commands do no harm. One of them is run automatically by cron, or when you boot up anyway.

Good Luck. Glad it's working now.

GrapefruiTgirl · 08-09-2009, 07:14 PM

GrapefruiTgirl · 08-09-2009, 07:14 PM

For the record, while kdesu now works, there is still some KDE4 bugginess (probably more than I have detected so far), particularly, once Konq started, I tried to open a console window from the Konq "Tools > Open Terminal" menu. It failed.

This sort of thing isn't toally new: On slack 11, sometimes kdeinit would bork, needing a restart.

In this case, I discovered that restarting kdeinit3/kdeinit4 did not do the trick, however doing `/etc/rc.d/rc.messagebus reload` fixed it. Everything worked after this.

NOTE: Don't execute `/etc/rc.d/rc.messagebus restart` or you will get thrown out to the login!

Sasha

jschiwal · 08-09-2009, 07:45 PM

I prefer running the KDE3 konqueror even in KDE4. Especially over using dolphin. I do file copying as root in konsole however.

gankoji · 08-10-2009, 10:25 AM

Quote:

AFAIK, there's no sudo included with Slack by default. I just ran `which sudo` and `sudo hello` both with no sudo found.

Actually sudo has come with Slackware at least since I've been using it (which isn't long, only since 12.0). Might have been something funny to do with your path?

Glad to hear everything worked out all right, I was actually surprised that it wasn't something pertaining to your ld.so.conf (actually, it could have been indirectly from your /tmp directory, but I guess we'll never know :-p). I'll keep this thread bookmarked for the next time KDE gets uppity.

GrapefruiTgirl · 08-10-2009, 10:49 AM

Code:

root@reactor:~# locate sudo
/etc/sudoers               
/var/cache/slackware64-current/slackware64/ap/sudo-1.6.8p12-x86_64-1.txz
/var/cache/slackware64-current/slackware64/ap/sudo-1.6.8p12-x86_64-1.txt
/var/cache/slackware64-current/slackware64/ap/sudo-1.6.8p12-x86_64-1.txz.asc
/var/run/sudo
/usr/share/zsh/4.3.10/functions/_sudo
/usr/share/vim/vim72/ftplugin/sudoers.vim
/usr/share/vim/vim72/syntax/sudoers.vim
/usr/share/icons/oxygen/22x22/apps/ksudoku.png
/usr/share/icons/oxygen/16x16/apps/ksudoku.png
/usr/share/icons/oxygen/64x64/apps/ksudoku.png
/usr/share/icons/oxygen/32x32/apps/ksudoku.png
/usr/share/icons/oxygen/scalable/apps/ksudoku.svgz
/usr/share/icons/oxygen/128x128/apps/ksudoku.png
/usr/share/icons/oxygen/48x48/apps/ksudoku.png
root@reactor:~# which sudo
which: no sudo in (/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/lib64/java/bin:/usr/lib64/java/jre/bin:/usr/lib64/java/bin:/usr/lib64/kde4/libexec:/opt/kde3/lib64/qt3/bin:/opt/kde3/bin:/usr/lib64/qt/bin:/usr/share/texmf/bin)
root@reactor:~# whereis sudo
sudo:
root@reactor:~# find / -name sudo
/var/run/sudo
root@reactor:~#

Heh heh, thanks for prodding me along there, gankoji! I was merrily producing, copying & pasting the above, from my console, to prove that there was no `sudo` on my Slack system, when while I was pasting it in here, I noticed the package /var/cache/slackware64-current/slackware64/ap/sudo-1.6.8p12-x86_64-1.txz there!

It should be noted that on Slack 11, I on several occasions looked around and never did locate a sudo package, it eludes me as to why *this* particular package is not installed right now on my -current installation..

Two possibilities (considering that I reinstalled the entire system the other say too):

1) package manager error?
2) No idea...

Anyhow, I think I'll just leave it where it is.. I don't need it

Cheers!
Sasha