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

This is a continuation from Post 15 and Post 16 because it's becoming IMHO beyond the 'newbie' forum (at least, this strace is-- :p it's beyond me, that's for sure..)



First, an observation:
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.. :scratch:

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.

.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:
As suggested in the other thread, I'll try a stock kernel and see what happens.

Sasha

You might try checking if the cached libraries exist:
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:
Mine:

[QUOTE=jschiwal;3635822]
Jim, I'm having trouble making the script execute:
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:
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

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. :scratch:

Sasha

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

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!

weird -- thanks for helping further JS
 

Done. No results other than some junk in the Trash, which I deleted.
That'd be init level 1 on Slack, which I'll try before rebooting this time, and empty /tmp.

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.

Yeah, me neither :scratch:
AFAIK, there's no sudo included with Slack by default. I just ran `which sudo` and `sudo hello` both with no sudo found.
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.
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

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 :scratch: 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.

Cue somber, scary music. A deep voice intones, "Somethings we were not meant to know!" ;) Glad you sorted your problem.
cheers,
jdk

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.

dupe

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

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

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.

:D 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

Well I have marked this thread as "UNsolved".

:banghead: This crap persists. I just wiped /tmp again, no luck. For the life of me I cannot start a root konqueror right now.
I just rebooted, to no avail.

I cannot WAIT :confused: until KDE4 (read: it's background processes, as I'm using XFCE again) is at least as usable as KDE-3.5.4 was.

too many freakin' daemons running around, none of them with their &%$#*@ heads on right.

I've reloaded messagebus, restarted kdeinit & kdeinit4, kill -HUP kdesud.. Can't just su to root and start Konqueror directly, because it complains about $DISPLAY not being set. If I set $DISPLAY, it tells me it can't connect to X server on $DISPLAY :banghead: and the odd time it pretends it's gonna 'connect', it quits, telling me DCOP_server session is missing. Can't win here. :(

the only way you can do that is if you run konsole or some other terminal emulator from within your current X session. so if you are on your XFCE desktop, hit alt+F2 and type konsole (or maybe xterm if you feel like not using kde's crap). then su, then konqueror. should do the trick!

nope, but thanks :)
 

Nope :( -- did exactly as you suggested:

Alt+F2 > `konsole` > `kdesu ...` = failed
Alt+F2 > `kdesu ...` = failed
Alt+F2 > `xterm` > `kdesu ...` = failed
Alt+F2 > `xterm` > `konqueror ...` = failed

Generally, I'd like to think that by this long investigating a proble,, I'd have a reasonably good idea where the problem is occurring, but I'm stumped -- especially with the inconsistencies of it working on occasion, but not usually.

Thanks for the added input, gankoji!

Sasha

The above is among the changes in the -current tree's latest changes/additions. While I haven't a clue why nobody else seems to be having this trouble, **maybe** that patch will do something :confused:

Maybe I need to wipe the partition, and reinstall the whole thing again, instead of upgrading.. That should fix it if this is due to screwy configuration, package overlap, or similar oddities.

Sasha

dude, thanks a ton! I was having kdesu troubles and that did the trick!

matti,

let us know if your troubles stay gone for good; mine are still here, and sadly, I've just adapted to them :\

1) kdesu
2) hit enter a couple times
3) enter password, get rejected, close dialog box
4) kdesu
5) hit enter at least once with no password
6) enter password, get accepted, hope application starts
7) if application didn't start, return to (4) and repeat

hi,

i'm afraid i won't be of much help. I stumbled upon this thread through a google search on how to solve kdesu trouble. I guess my case is totally different (I even didn't fully get your problem as it seems to be detailed on other forum posts), but it happened to be solved through the advise found in this thread. sorry to disappoint you, my problem is fully solved, but it was probably not really related to yours. When I launched kdesu, simply nothing happened. that was my problem :) now everything still works after removing the /tmp files.

cheers
matthias

Since fully re-installing virtually my entire system on top of itself in one shot, rather than running the previously rsynced situation I had been running during the process of upgrading & testing -current, I can now confirm that `kdesu` is working as it should :D :D

So, I must have had some slight mess with some packages or libs, perhaps due to slight overlap/underlap of packages while maintaining the system via rsync. Don't really know for sure, but it's now working!

I wish to thank everyone who contributed thoughts and information during the course of this thread: Thanks!

Cheers!
Sasha

lol, I'm glad for you, congrats! =)