Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
About 5 months ago, or so, X (Gnome) began to take a long time to load - seemingly 4 or 5 minutes from the time the mouse pointer appears until the Gnome desktop is fully loaded. It didn't really concern me, and it still doesn't, really, but I am curious as to what's going on, and why.
In browsing my messages log, it appears that this is what's causing undue delay:
Apr 14 20:53:35 main smbd: [2006/04/14 20:53:35, 0] lib/smbldap.c:fetch_ldap_pw(312)
Apr 14 20:53:35 main smbd: fetch_ldap_pw: neither ldap secret retrieved!
Apr 14 20:53:35 main smbd: [2006/04/14 20:53:35, 0] lib/smbldap.c:smbldap_connect_system(813)
Apr 14 20:53:35 main smbd: ldap_connect_system: Failed to retrieve password from secrets.tdb
Apr 14 20:53:36 main smbd: [2006/04/14 20:53:36, 0] lib/smbldap.c:fetch_ldap_pw(312)
Apr 14 20:53:36 main smbd: fetch_ldap_pw: neither ldap secret retrieved!
Apr 14 20:53:36 main smbd: [2006/04/14 20:53:36, 0] lib/smbldap.c:smbldap_connect_system(813)
Apr 14 20:53:36 main smbd: ldap_connect_system: Failed to retrieve password from secrets.tdb
Apr 14 20:53:37 main smbd: [2006/04/14 20:53:37, 0] lib/smbldap.c:fetch_ldap_pw(312)
Apr 14 20:53:37 main smbd: fetch_ldap_pw: neither ldap secret retrieved!
Apr 14 20:53:37 main smbd: [2006/04/14 20:53:37, 0] lib/smbldap.c:smbldap_connect_system(813)
Apr 14 20:54:21 main smbd: [2006/04/14 20:54:21, 0] passdb/pdb_ldap.c:ldapsam_search_one_group(1971)
Apr 14 20:54:21 main smbd: ldapsam_search_one_group: Problem during the LDAP search: LDAP error: (unknown) (Timed out)
Obviously, this is related to samba and lpad, but I don't have an issue with samba and how it performs for me (that I'm aware of, anyhow)
So, could some kind soul please explain to me what's happening, or not happening here, and how to either make it happen, or not, so that X may load quicker, and I can find something else to enquire about in another few months?
because it's not 'starting samba' that's the issue, it's booting, or loading X, that's the issue.
Alas, there is still a huge delay from the time the blue-screen-mouse-cursor appears until the desktop loads. Here's the latest from messages:
a bunch of stuff looking good.....then:
Apr 15 18:32:54 main nmbd:
Apr 15 18:32:54 main nmbd: *****
Apr 15 18:32:58 main gdm-autologin(pam_unix): session opened for user main by (uid=0)
Apr 15 18:33:00 main gconfd (main-2350): starting (version 2.10.0), pid 2350 user 'main'
Apr 15 18:33:00 main gconfd (main-2350): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0
Apr 15 18:33:00 main gconfd (main-2350): Resolved address "xml:readwrite:/home/main/.gconf" to a writable configuration source at position 1
Apr 15 18:33:00 main gconfd (main-2350): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
Apr 15 18:33:04 main noip2: v2.1.1 daemon started with NAT enabled
Apr 15 18:35:04 main gconfd (main-2350): Failed to send buffer
Apr 15 18:35:06 main gconfd (main-2350): Resolved address "xml:readwrite:/home/main/.gconf" to a writable configuration source at position 0
Apr 15 18:35:40 main ntpd: synchronized to LOCAL(0), stratum 10
Apr 15 18:35:40 main ntpd: kernel time sync disabled 0041
and X loads, and we're off to the races....
As you may notice, there is a full 2 minutes of 'inactivity' between the time noip2 loads and the message:
Apr 15 18:35:04 main gconfd (main-2350): Failed to send buffer
So the samba-lpad issue appears to have been only part of the whole issue.
Again, not sure if this will help, but recently I had a problem with loading Metacity which turned out that SELinux was preventing an openGL shared library from being read. I first turned SELinux off all together to see if it was the problem, which obviously it was, then made a rule to allow that library to be read.
It's a long shot, but perhaps temporarily disabling SELinux might show you the problem??? As samba-lpad has turned out not to be the issue but merely a symptom of the issue, your trouble must be from deep within the core of Linux, maybe!?!
I unfortunately don't have an immediate answer for you but the more we sniff around the closer we'll get to the turd in you system.
First off, let me express my appreciation for following this thread.
I don't have SeLinux turned on, so that's not the issue.
Also, keep in mind, from my original post, that I don't consider this to be a huge issue. In fact, it's the only concern I have, at the moment.
It's just occurred to me that the problem only happens with one particular user login, which also happens to be setup as an autologin, hence occurring on reboots.
Obviously, a solution is to create a new user, and delete the old, but then we'd never know what was causing the problem. Plus, there'd be those precious few minutes getting the new desktop/user just 'right'. Fortunately, that's not a big deal (because I'm not the affected user....)
Before I take that step though, are there any likely places I may look in the user's ~ to track this down?
Hmm... I unfortunately have the infliction that when I have even a small problem I just can't sleep until I figure it out!
The first place I'd start is to stop any apps from auto-starting so X is started & nothing else, if this works then auto-start one of them at a time until you get the same problem, then delete the dot-config dir for that app, restart it, which will create a new dot-config dir.
But this probably won't work, so the next thing I'd try is to move the .gnome2 dir to somewhere else & start X again, more than likely some config file in there has become corrupted. Gnome will automatically create a new one so if this works you can simply copy the file called "session" & the dir called "panel2" from your old .gnome2 dir to the newly created one & the next time you login your gnome session should be as you remember it.
Thanks for your help - it turned out to be an issue with a session startup program, which I disabled, then re-enabled, and it's fine. Don't know why.
I've found a couple of other issues; now samba is messed up (I've posted that problem elsewhere), and I'm puzzled as to what to do if fstab is loaded before samba starts, how can samba shares be mounted?...hmmm, samba seems to be running in the top 5 issues brought forth in this forum.
anyway, some stuff to concern myself with in the near future....
Please post a link to your samba question for me to take a look at.
As for fstab, mounting all in that file occurs long before any daemons, including samba, are started, as you probably know, this is necessary for samba shares to be mounted anyway! so I'm a little confused as to your problem, maybe reading your other question will help.
When you say "fstab" I'm assuming that you mean the file /etc/fstab, this file contains all the partitions & their mount locations that need to be mounted for your system to operate, of course. The fact that you have to run "mount -a" to get these to mount is very strange indeed!! as "mount -a" is one of the commands in the startup script /etc/rc.d/rc.sysinit.
If the entries in your fstab file aren't being mounted during bootup by your system startup scripts then this means that something is very wrong with this script!
What distro are you running, have you modified any scripts in /etc/rc.d, during boot does everything say "[ OK ]" ????
There are ways around this but it should not be happening in the first place!
Well, without going into too much detail, I have solved the problem.
Netfs wasn't able to mount the samba entries in fstab, hence they weren't showing up when X started. A 'mount -a', as root, would mount the samba entries. Non-root users couldn't use the 'mount -a' command, so I ran a chmod on the mount command, and that worked, briefly, but then I would get various errors (as non-root; root would still work.)
Since I was able to mount the shares using the mount -a command, I believed that my fstab entries were correct. However, they weren't (though, as root, 'mount' managed to make it work....)
So, I fixed the fstab entries, and now everything works as it should.