I've noticed while testing that when libnss has problems it sends a emergency message to syslog which pops up messages to everyusers connected though the terminal "canot connect....." even when there in terminal programs like pico. This happens in when it's in debug mode and when it isn't
For us this is a critical issue since 90% of the work on the server is done though the terminal and those messages mess up there program.
It would be great if these messages went to a logfile instead of a emergency message. I can change syslog but then my users won't get shutdown messanges and the like.
Thanks,
Keith
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with you on this. I've been meaning to clean that up; it's a holdover from the earlier beta days when problems (due to bugs) cropped up and I wanted to know when a problem ocurred :-)
I'm going to try to release 0.7a soon to patch up a few things, including this one.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I downgraded the messages from LOG_EMERG to LOG_ALERT. If you're still getting messages, then your syslog is configured to send ALERT messages to the console, which is abnormal. None of my machines get the messages anymore, so I have to believe that either your installation of 0.7a didn't take, or your syslog is configured to allow more than just EMERG messages to make it to the console. What does your syslog config look like?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you're right. How can I tell if my installation has taken? I can see the lib there but is it dynamic or do I have to start/stop something.
Also I've noticed on a couple machines where I had problems I took mysql out of nsswitch.conf to stop getting the log messages. Then even a day later I was still getting the messages. This paticaular machine still had the nss library, had mysql running as the main mysql userdb for my other nss machines.
Anyways how can I tell if nss is still running, how can I kill it without restarting mysql.
Thanks for all the help. I'm testing all I can with this in a production envrionment.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's no quick way to find out, other than to run an 'ident' on the installed file and match up the revision number of the latest source file to the one in your source directory. I'll be putting the main version number inside soon so it's more readily seen.
libnss-mysql doesn't behave like a daemon itself; however, any daemon that accesses user information will load the library and keep it loaded until the daemon is restarted. The only way to unload it is to restart the daemon itself. And the way to find out what daemon is using it is to simply look at the pid number that's in the syslog message. It may be easier to reboot, depending on your situation.
I don't see any way around this, either. It's the way the operating system behaves.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've noticed while testing that when libnss has problems it sends a emergency message to syslog which pops up messages to everyusers connected though the terminal "canot connect....." even when there in terminal programs like pico. This happens in when it's in debug mode and when it isn't
For us this is a critical issue since 90% of the work on the server is done though the terminal and those messages mess up there program.
It would be great if these messages went to a logfile instead of a emergency message. I can change syslog but then my users won't get shutdown messanges and the like.
Thanks,
Keith
I agree with you on this. I've been meaning to clean that up; it's a holdover from the earlier beta days when problems (due to bugs) cropped up and I wanted to know when a problem ocurred :-)
I'm going to try to release 0.7a soon to patch up a few things, including this one.
I got the new 0.7a and did a make and make install and I still get those messages going to the terminal.
Our business can't operate with theses messages popping up, it kills there program, so I've had to disable the emergency syslog messages.
Keith
I downgraded the messages from LOG_EMERG to LOG_ALERT. If you're still getting messages, then your syslog is configured to send ALERT messages to the console, which is abnormal. None of my machines get the messages anymore, so I have to believe that either your installation of 0.7a didn't take, or your syslog is configured to allow more than just EMERG messages to make it to the console. What does your syslog config look like?
I think you're right. How can I tell if my installation has taken? I can see the lib there but is it dynamic or do I have to start/stop something.
Also I've noticed on a couple machines where I had problems I took mysql out of nsswitch.conf to stop getting the log messages. Then even a day later I was still getting the messages. This paticaular machine still had the nss library, had mysql running as the main mysql userdb for my other nss machines.
Anyways how can I tell if nss is still running, how can I kill it without restarting mysql.
Thanks for all the help. I'm testing all I can with this in a production envrionment.
There's no quick way to find out, other than to run an 'ident' on the installed file and match up the revision number of the latest source file to the one in your source directory. I'll be putting the main version number inside soon so it's more readily seen.
libnss-mysql doesn't behave like a daemon itself; however, any daemon that accesses user information will load the library and keep it loaded until the daemon is restarted. The only way to unload it is to restart the daemon itself. And the way to find out what daemon is using it is to simply look at the pid number that's in the syslog message. It may be easier to reboot, depending on your situation.
I don't see any way around this, either. It's the way the operating system behaves.