Linux - root logs on, user can't; "Error in service module"

You already tried my first idea, resetting the password for the user account. So let's try to figure out what is happening.

Idea #1:

Log in as root. See if you have the "sux" command. Many distributions don't. If you are running a GUI then open a terminal window. At the command line enter the following command:

which sux

If you get your command prompt without any other information then you don't have the sux command.

Let's say that your user account is named user01. If you have the sux command then do this when you are logged in as root:

If you have a GUI running then open a terminal window.
At a command line enter the following command.

sux - user01

Hopefully you will see some specific error messages that will help diagnose this problem.

If you don't have the sux command then try this as root:

su - user01

Again we hope that some helpful user messages will be displayed.

========

Idea #2:

Log in as root. If you are running a GUI then open a terminal window.

At the command prompt enter the following command:

init 3

Hopefully the computer will stop the GUI and restart in text console mode. Then you can try to log on as the normal user. If you get logged out then log on as root and try the su - user01 command again. See if you have better luck getting logged in.

The purpose of this idea is to determine if your log in problem is due exclusively to the GUI settings.

========

Idea #3:

After you've done those things read the /var/log/messages file. There may be helpful messages there.

Open a terminal window. Enter the following command.

tail -100 /var/log/messages

or

cat /var/log/messages

It sounds like you've wedged the PAM service. If I'm not mistaken, that error message (error in service module) is specific to PAM, particularly if it's related to logging in. Judging by the logfile entries you've posted and the fact you're using Fedora, it's highly likely that you did something that caused SELinux to flip out, hosing up your user account login.

You might try restarting services related to PAM and SELinux.

If that fails, it may be quicker to try logging in as root and restarting the system ([b]init 6[/b] or [b]shutdown -r now[/b] will do it on basically any Linux system if you're at the command line and logged in as root, in case you're not familiar with the shell syntax for a reboot). Of course, if you want to make sure you know exactly what the problem was, you may not want to take this "easy way out" -- and it's not guaranteed to work.

SELinux configuration is so complex that troubleshooting problems with it tends to be akin to black magic, waving chicken bones over the computer and chanting the names of evil spirits. Hopefully, it's something that is easily remedied via restarting services or PAM configuration.

Apparently SELinux is part of the default Fedora installation. I'd never heard of it before you two mentioned it and I had to look at the manpage to get some idea of what it does.

I don't mind creating a new user for troubleshooting, I just regard that and moving files as a "solution". I created a new user, but it wasn't able to log on either.

I noticed something interesting (at least, interesting to me). When I attempt to log on as either non-root user (my original user account or the newly created one), I'm unsuccessful both in and out of the GUI. However, the system responds differently depending on whether or not I enter my password correctly.

Sequence with correct password:

Fedora Core release 5 (Bordeaux)
Kernal 2.6.17-1.2174_FC5 on an i686

MACHINENAME login: username
Password: correct_password

Error in service module
<>
login:

I don't know if this confirms previous theories or indicates something else. To me it seems to indicate that with the correct password I'm getting authenticated by at least one mechanism.

# su - user01
su: incorrect password

How do I enter a password for su? According to 'info su', it should prompt me for one. I've unsuccessfully tried:

# su - user01 password

and

# su - user01:password

My SELinux expertise tells me this:

Never ever use SELinux unless you must actually make use of its fine-grained security access control capabilities. So far, that hasn't happened to me. SELinux has almost unlimited potential to screw things up royally for those who are not already experts in its use. It is way above and beyond the security needs of most users.

I believe that there are two things that you have to do to disable SELinux. 1) Disable SELinux in the kernel. 2) Copy my /etc/pam.d/login to your system. Make a backup of your own copy first. Get a bootable Linux live cd to make repairs if the system becomes unbootable.

1) Disable SELinux in the kernel via a boot parameter.

[CODE]
kernel (hd0,0)/boot/vmlinuz root=/dev/hdb1 selinux=0 splash=silent ...
[CODE]

Notice the part that says "selinux=0". That's the part that disables SELinux in the kernel at boot time.

That line came from my /boot/grub/menu.lst file. If you are using LILO then you will have to pass the "selinux=0" to the kernel another way. I don't remember how to do this with LILO.

Make a backup of your /etc/pam.d/login file, then copy mine to your system. You will need to log in as root to do this. Since that is your only choice then you're okay in that respect.

[CODE]
cd /etc/pam.d
mv login login.selinux
[CODE]

Use an editor to create the new /etc/pam.d/login file. Cut and paste the example that I put in a previous post. Exit the editor. Make sure that the new /etc/pam.d/login file can be read by anybody as follows.

[CODE]
chmod -c o+r /etc/pam.d/login
ls -l /etc/pam.d/login
[CODE]

You should see this.

[CODE]
$ ls -l /etc/pam.d/login
-rw-r--r-- 1 root root 328 May 2 04:50 /etc/pam.d/login
[CODE]

Now cross your fingers and reboot.

This is an academic exercise on a non-production desktop. I can break it and start over all I want, but I'm not sure what I can learn from this experience. What's the lesson here?

Not to strike the keys in alphabetical sequence?

Research every single application in a distro before I install it's desktop configuration?

Don't let yum do automatic updates?

This is -most- discouraging. I didn't think Linux would allow me to do this kind of damage logged on as a non-root user.

:)

Okay. Apotheon and I don't understand SELinux.

Interesting. See if the user account is in the user account file, /etc/passwd.

[CODE]
grep newusername /etc/passwd
[CODE]

You should see something like this. Here I am searching for the user account named boinc.

[CODE]
root> grep boinc /etc/passwd
boinc:x:1007:100::/var/home/boinc/BOINC:/bin/bash
[CODE]

You can see that the boinc account has a UID of 1007, it is a member of GID 100, its home directory is /var/home/boinc/BOINC, and it's shell is /bin/bash. This is fairly typical of normal user accounts, except for having the home directory under the /var directory.

Note that the "x" in the user account record just after the user name is significant. It means that the user account has its password in the /etc/shadow file. If there were any other character there it could mean that the user account is disabled.

http://fedoraproject.org/wiki/SELinux/Troubleshooting

"If you want to disable SELinux, you need to edit /etc/selinux/config and change the SELINUX line to disabled. You will then need to reboot the machine, since SELinux is running within the kernel."

Unfortunately, it hasn't made a difference.

#grep testuser /etc/passwd
test1:x:501:100:test1::/bin/bash

There's no home directory listed because when I used the GUI user mgmt. tool, I unchecked the "Create a home directory" box. I did this so I would have one less thing to clean up when I deleted the user. Must a user have home directory to log on?

1. Never install SELinux. If using Fedora, ensure you disable SELinux during installation.

2. Never use Fedora.

The requirement for a user to have a home directory in order to log in is determined by a setting in the /etc/login.defs file. Here is an exerpt from that file.

[CODE]
# Should login be allowed if we can't cd to the home directory?
# Default is yes.
#
DEFAULT_HOME yes
[CODE]

There are a lot of other user account related goodies that are configured in that file.

By the way, look to see if there is a file /etc/nologin on your system. If there is then delete it. Just delete it. Then try to log on as a normal user again.

The /etc/nologin file is created during a system shutdown to prevent normal users from logging in as the system is being shut down. It can also be created at any time by the system administrator to prevent user logins. I just tested it by creating an empty file with that name and then trying to log on as a normal user. I expected to get a message like "Logins are disabled". Instead I got "Incorrect password". That's a bit of a red herring.

So see if you have that file (/etc/nologin). If you do then delete it. Then try to log on as a normal user that has a home directory.

Palmetto,

the Fedora wiki page that you referenced DOES appear to say that changing the config file would have the same effect as what I had mentioned "selinux=0" as a kernel parameter. See my newest, and best, post above about the /etc/login.defs file and the /etc/nologin file.

apotheon,

I wouldn't go so far as to say not to use Fedora. I'm sure that you are joking. When you come right down to it one Linux distro is much like another. I know that you like Debian so I'll rephrase. One Linux distro is much like another but Debian is best. How's that? :)

that is where that log resides.

Dan

# cd /etc/ssh
You have new mail in /var/spool/mail/root

I recall something about Linux using a mail system to deliver system messages, so I assume that's what that is. I'll take a look at that when I finish posting this. I wonder why I didn't get that message until I switched to the /etc/ssh directory?

You don't remember if I said it was an ssh login because I haven't said anything about ssh until now. What's an ssh login, and what are the alternatives. And here I thought a login was a login. Silly me.

Without all the commented lines, the sshd_config file looks like this. I don't see anything telling me what it's using for a log file.

Protocol 2
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAutentication yes
GSSAPICleanupCredentials yes
UsePAM yes
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
X11Forwarding yes
Subsystem sftp /usr/libexec/openssh/sftp-server

Commenting out the two lines in the login file had no effect.

# cd /etc
# ls -l passwd
-rw-r--r-- root root 1787 sep 14 10:54 passwd
# ls -l shadow
-r-------- root root 1178 sep 14 10:54 shadow

which appears to me to indicate the shadow password file is set so no one can change it, not even root, and that only root can read it.

# chmod u+w,g+r shadow
# ls -l shadow
-rw-r----- 1 root root 1178 Sep 14 10:54 shadow

to match yours, but still no go. I really thought that was going to do it. I had already keyed in "Now we're getting somewhere!" at the bottom of this post and had to delete it.

Quoting from

http://www.redhat.com/archives/pam-list/2000-December/msg00107.html

"'Error in service module' indicates a fatal error in the PAM environment, typically one that can't be explained or recovered from."

I don't know if the guy who said this knows what he's talking about, but it is one of only two references I could find on the web that directly addressed this error message. The other said to comment out the last three lines in /etc/pam.d/login. I didn't regard the sender as very knowledgable since he didn't include the code involved, just "the last 3 lines", obviously assuming everyone had a login file identical to his. I tried it anyway but no go.

Lessons learned: Well, I'm not sure I learned not to install SELinux. As I said, the only references to the error referred to PAM, not SELinux. I didn't learn not to accept a preconfigured installation package. At this stage I have to accept a package; I don't yet know what to pieces to select if I wanted to pick and choose. I guess I learned to accept a minimum installation configuration and add to it as I go. That's a little disappointing with something that's supposed to be a turn-key solution. I confirmed something I already suspected: I'll get faster, better, and more answers at TR than at Fedora Forum, Linux Forum, or Linux Questions.

Unfortunately I still don't know what broke or how I broke, the really useful lesson I would have preferred to learn. This is why I hate the "Keep breaking it" method of so-called "learning".

Thanks to everyone for their suggestions (stress junkie, you present instructions and processes very clearly), but it's reinstallation time. Have a good weekend.

Updated - As I went through the reinstall, I notice there is no "Minimun" installation option, just "Desktop / Productivity", "Development", and "Web Server". I took D/P, and as I wandered through the software options I remembered I had done this the first time. I didn't just accept the D/P package as configured the first time; I looked at what it was going to install and removed the things I KNEW I wouldn't need initially (OpenOffice, graphic utilites, games, media players, languages, etc.) So I didn't even learn that lesson; I already knew it. While I do have the option to pick and choose what "core" or "base" packages to install, I don't know enough about them to know if I can leave any out (daemons, drivers, services). Most of them have abbreviations or acronyms in the description so what they do isn't readily apparent.

I hang out at linuxquestions.org a lot more than I hang out at TR, and I have the same moniker at both sites. I'm sorry I didn't see your post there. Not that my suggestions would have been any more valid there than they were here. :(

I wish that I had suggested using strace earlier on in this process. You get a lot of output but whatever is going wrong would be near the end of the output.

1. Every time you enter a command, the system checks to see whether there are any new mail messages waiting for the user account you're using. If so, it gives you notification of that fact. The reason it didn't tell you until you accessed that directory is that the root account received that message after the previous command you entered as root.

2. It seems that your MTA (mail transfer agent) is configured to deliver messages for root to root. It's usually a good idea, if you're the system administrator, to have messages for root delivered to your normal user account since you'll be logged into that account more often. It's not that big a deal, but that's fairly common practice.

3. By "an ssh login", he just means to ask whether you're logging in via SSH, a client/server protocol used for secure, encrypted logins across a network.

4. sshd normally logs to /var/log/syslog

If you'd like more information about configuring and using SSH, this might be a good place to start:

http://articles.techrepublic.com.com/5100-3513-6096973.html

1. I don't know much about PAM right now. That may change in the near future, but for now I only have general troubleshooting help to offer.

2. Troubleshooting something like this is quite difficult to accomplish over an online discussion forum. As such, if it comes to that, you could always get in touch with someone like SJ or me off-site and arrange for one of us to have SSH access to your machine over the Internet so we can have a more hands-on look at it and try to solve the problem a lot faster and more effectively.

3. On the other hand, for security purposes, I recommend against taking the route toward solution that I described in point 2. Don't give us (or anyone else, for that matter) root access to your machine. It just isn't safe. I wouldn't do anything but try to fix the problem and help you out if you gave me root access, of course, but you don't know that -- so don't.

Yeah, this was a mostly useless post.

It's too late to check either file since I've already done a reinstall, but I don't think the original symptoms fit your suggestion.

I went from successfully logging on to dead in the water in one reboot. It's possible I mistyped the password once, but it's the same one I've been using for my Active Directory admin account for three months and I type it several times a day. On a average I mistype it once a week. It's always possible I mistyped it twice in a row, but after I strike out twice I usually quit touch-typing and use a single finger one key at a time. Also, a second test account I created from scratch was never able to log in.

I'll keep this in mind if the problem reappears on the reinstalled version. Thanks.

I know this thread is a year old, but I had this exact same thing happen to me, the symptoms were identical point for point.

It turns out that on a reboot, the service winbindd wasn't starting, so a simple /usr/local/samba/sbin/winbindd start and lo and behold normal users were able to log back in.

Just a quick fyi incase anybody comes across this problem/thread like I did.