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.
When I use the "users" command it shows me a list of users that are in the system. For some reason however the users that it lists are not the proper users in the system. For instance if John, Sara and Rosa are logged in, and it lists Mike Jessica and Kathy insted. Sometimes it lists usernames twice, and sometimes the correct usernames come up, but for the most part they show incorrectly. We have had this problem before and when we restarted the server it corrected itself. We are looking for a way to correct it without restarting the server. (My boss is finicky about restarting)
Why not use the w command. It will show you who all is on the system, along with what they are using. Please note that it too will give you multiple instances of a user, depending on what all they are doing, but, if you want just a list, try something like
Well, I'm not really sure then. It should have shown at least the user that ran the command. And I'm not sure why it would show an incorrect user. (Incorrect I am taking to mean a user that is not currently logged into the system.) Both the users and w commands take information from the /var/run/utmp file by default (users can be fed a different file apparently). Is there anything wrong with that file? Looks like it should be 664 root:utmp. Do you have another process that has been set up to write to that file per chance?
Your definition of incorrect was what I meant, sorry about not being specific enough. Yes it is currently 664 root : utmp. Is there anyway to recreate/rebuild the file while the server is running? Or is it something that only happens when the system is rebooted.
Thanks for all the help
Last edited by Sarolearthy; 03-28-2006 at 12:39 PM.
664 root:utmp would be the permissions (rw-rw-r--), and owner:group, so that all looks ok. The file is binary, so regular editors won't do the trick. You can put it through strings to have a look at it
strings /var/run/utmp | more
Though I'm afraid that it isn't going to really help a lot. Mine looks like ...
From what I can figure out, it appears to be a list of available terminals (tty1, is the terminal that you switch to if you press Ctrl-Alt-F1). I am logged in as root on tty1, and as myself via KDE. Where it says LOGIN it is awaiting a log-in. I have no idea what the (Dxx listings are about.
I'll have to look and see if I can find anything about re-starting the service that writes to that file (once I figure out what it is), but have someone comming by to install a DVD burner for me in a few minutes, so it might be a bit.
I tried the strings command that you listed and I think it helped us narrow down the problem, or at least I hope. The file is seemingly a neverending list of terminals, some repeating. Could it be that, that for what ever reason when people log out they are not being removed from this list and its causing conflicts?
It could be possible, though I would hope not as it appears that the init process is what writes/updates that file. And if there is an issue with init ...
You can try sending SIGHUP to init and see if it in some way cleans up that file. I'm not really sure if it would delete/recreate that file or not, but you can give it a whirl. Shouldn't hurt your system none (I've done it offten on our Solaris boxes).
First, you'll need to find the PID of the init process and then send SIGHUP.
ps -ef | grep -v grep | grep init
Note that you'll probably get a few lines returned. Look for the one that is init all by itself. The PID is the second column. For me, it turns out to be the first process, so ...
Ok. I've been looking at this a bit more, and even deleted my /var/run/utmp file to see if it would be re-created. It wasn't. It did write to that file if I were to log in from a different terminal after that, but that isn't going to correct your problem as you won't have anyone currently logged in written to the /var/run/utmp file unless you make everyone log out then back in.
The only other thing that I can think of that might be your problem is if your user ids have been re-used, but chances are you would have noticed this in other ways by now (people with a $HOME that is different than what it should be, things like that) so I doubt that that is the problem.
Everyone who works in my company logs out at the night, so if deleting would reset the file so that when everyone would log in next it would re-create and be up to date that would be acceptable. I'm not sure if where implying the file would be re-created or it would write the information elsewhere.
Oh and that command did work, thank you very much. I would still like to find a way to fix this file in the event it has any effects on any other programs we have, we've notice sometimes the incorrect (not logged in users) are showing up on double vision, but when you take control of that user it'll end up being an entirely different user currently logged into the system.
Well, I'm glad that command works for you. I really wouldn't suggest deleting that file until I knew what all depends on that file. I deleted it because it was on my laptop, and I can easily re-install should it really flub up the system (though I think a re-boot would do it as well). As it sounds like you are running a live server, those options are not anywhere near as appealing.
I'll continue to look at this a bit more in my spare time (installing Oracle 9i on a server and are ramping up to start putting 10g on all of ours in the near future). I'll let you know if I find anything.