Registered Member
|
%file /usr/local/kde4/lib/kde4/kded_ktimezoned.so gives:
/usr/local/kde4/lib/kde4/kded_ktimezoned.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, stripped |
Administrator
|
Please post the readelf output (following the command given by luebking) as well as the ldd output. It is extremely odd that the system would claim it is unable to open a library when it is infact readable by your user.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
Registered Member
|
% readelf -s /usr/local/kde4/lib/kde4/kded_ktimezoned.so gives:
%ldd /usr/local/kde4/lib/kde4/kded_ktimezoned.so gives:
|
|
Just to be sure: it's a 32bit installation, yes? (check the kded binary) Beyond that: any other security levels in place (ACLs, or is there eg. sth. like "SEBSD"?)? If not i could only assume that one of the linked libs is junk - but you'll have to ltrace & strace kded in order to see what's really going on here. Is this btw. a self compiled/installed KDE or provided by your BSD distro? |
Registered Member
|
It's 32bit.
No jails or chroot. Distro, straight off the install DVD. The rest of the system functions flawlessly. Fluxbox (and even KDM) picks up the /etc/localtime without a problem. In System Settings > Global Policy Configuration > System Settings it has [Group] [ (blank) ]. Could that be an issue? |
|
I don't even have that item...
Because getting the local time is idiot-proof. I think the timezond is used to allow runtime changing of the zone and w/o privilegue elevation. I'd suggest to skip focusing on that complaint because the inability to load kded modules goes far beyond it: a) because you'll lack some features b) because you can expect whatever breaks this to cause more trouble. strace and ltrace kded and check why the file cannot be opened - it's extremely odd and at this point i cannot think of any futher reason, so please let the system tell you. (if you want to grep strace output, do "strace kded 2>&1 | grep foobar" - it writes nearly everithing to stderr) |
Registered Member
|
It's actually: System Settings > Global Policy Configuration > System Settings: System Administrators (System Administrators being the landing page of GPC)
BSD box, so no strace, truss instead... #truss /usr/local/kde4/lib/kde4/kded_ktimezoned.so gives:
Honestly, I don't care much about the modules that can't start other than ktimezoned. The rest are trivial at best, like games. It just annoys me that the backend to KDE's clock is built so completely, for lack of a better word, stupidly. I see absolutely no point in it reading anything other than /etc/localtime. If the complexity in the build were done so that a person could automate the linking/copying of /usr/share/zoneinfo... I still don't unsterstand why the Set Date & Time analog clock, KDM login and everything else on the machine gets the right time. Somebody, in my opinion, wanted to show off and over-built the app. On top of that every single time/clock widget is locked into the same stupid module. So... Idiot-proof? Tell that to who ever decided that it wasn't then went ahead and built a secondary system that keeps breaking down. |
|
> open("/usr/local/kde4/lib/kde4/kded_ktimezoned.so",O_RDONLY,027757753220) = 3 (0x3)
successfully opened file > fcntl(3,F_DUPFD,0xa) = 10 (0xa) successfully duplicated handle to ... close(3) = 0 (0x0) successfully closed original handle fcntl(10,F_SETFD,FD_CLOEXEC) = 0 (0x0) ... successfully alter the handles attribute to autoclose with exec. Next this is you interrupting kded. Nothing here suggests that opening the library was no possible - on the contrary. i checked and kded yells the warning only in case KPluginFactory *factory = loader.factory(); failed and the other branch has a "// kde3 compat" comment on it, ie you likely should not be there anyway. What looks suspicious in your elf table are the additional WEAK KPluginFactory entries, which look like local overrides of the kdelibs functions. Can you run "readelf -sW" on it (wide output, will show full symbol names) Have you ever asked at your BSD distro whether this (complete KDED failure for not loading plugins) is a known issue there? |
Registered Member
|
The first 3 are the only instances of KPluginFactory (or kpluginfactory) on the machine. I tried with KPluginLoader as well. Let me know if I'm spacing out on something here No, I have not asked anything about this in the FreeBSD forums or mailing lists. However, I have searched until my eyes have started to twitch! I am a bit shy about asking Q's at the fbsd forums as there are a couple of ppl there that love to be complete DB's about any and everything and they are administrators (which is quite lovely). Anyway, I'd quickly get sent here none the less as nothing. is. ever. their. problem. |
|
# readelf -sW /usr/local/kde4/include/KDE/KPluginFactory
readelf: Error: /usr/local/kde4/include/KDE/KPluginFactory: Failed to read file header # readelf -sW /usr/local/kde4/include/kpluginfactory.h readelf: Error: Unable to read in 0x706f bytes of section headers readelf: Error: Not an ELF file - it has the wrong magic bytes at the start # readelf -sW /usr/local/kde4/share/sip/PyKDE4/kdecore/kpluginfactory.sip readelf: Error: Unable to read in 0x6e40 bytes of section headers readelf: Error: Not an ELF file - it has the wrong magic bytes at the start you cannot readelf includes or other plain text files, that's expectable, but this: # readelf -sW /usr/local/kde4/lib/kde4/kded_ktimezoned.so readelf: Error: /usr/local/kde4/lib/kde4/kded_ktimezoned.so: Failed to read file header is suspicious, notably since you apparently had no trouble reading it before. Also (just noticed): > #truss /usr/local/kde4/lib/kde4/kded_ktimezoned.so gives: You actually should have truss/strace'd `which kded4` pkill kded4; truss kded4 Then run "kcmshell4 kded", try to load the timezone daemon and watch the truss ouput on that. |
Registered Member
|
#truss which kde4
Then: #pkill kded4 #truss kded4
%kcmshell4 kded
One other thought. I deinstalled/reinstalled kde4-runtime then cleared .xsession-errors and rebooted to see if anything had changed. Could this:
in .xsession-errors be caused by installing (and/or) first running Qt/D-Bus as a non-wheel user then later being added to the wheel before installing KDE4 and KDM? Everything I'm seeing (at least the parts that make sense) seem to be pointing at a permission level in anything relying on D-Bus. |
Administrator
|
That is quite unusual - does the binary "kded4" exist on your system? Based on the weirdness of the above output I would strongly suggest verifying the integrity of the underlying file system and completeness of your KDE installation as it is not behaving correctly. In terms of why ktimezoned is necessary - it reads information on all timezones and caches it for use by all parts of KDE to use as they need to - the clock uses it to provide a list of timezones for instance.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
Registered Member
|
/usr/local/kde4/bin/kded4 and /usr/local/kde4/lib/libkdeinit4_kded4.so both exist. Any checks I should run on them?
I understand why ktimezoned is necessary. I just don't understand why there is no override to allow for direct display of /etc/localtime in plasma clocks. |
Registered Member
|
Sorry, bcooksley, I ran truss on kded4 as root >.<
%truss kded4 (first half)
|
Registered Member
|
(second half)
Didn't want to leave anything out |
Registered users: Baidu [Spider], Bing [Bot], Google [Bot]