Running the login program from a remote shell in order to log in a second time "locally" fails to properly update utmp/wtmp. If you log in via ssh, then log in again manually by running the login program then log out of that second shell, utmp/wtmp seems to have totally forgotten your original environment, because you are no longer listed in a w or a who, and doing last (username) does not return that the user is still logged in. I have posted to freebsd-questions and have found several other people running 5.3-RELEASE who can reproduce this problem. I have spoken with a 4.10 and 5.3-STABLE administrator who cannot reproduce the problem on those systems. No one on the lists has been able to explain or attribute to a config error. The only way to see connected users in this invisible state is to view open sockets, count running sshd processes, or snoop on the tty the user happens to be on (which you can figure out from the sshd process.) As you will see below, insofar as the wtmp/utmp records go, running the login program seems to totally discard the initial login environment as if the user had logged out completely. One person on fbsd-questions suggested this was expected behavior for the login program, since the man page says by default login discards any previous environment. If this were truly the case, exiting the second shell should exit the user from the system rather than return them to a "discarded" environment. Fix: Chmod the login program so that only root can run it. This will allow the initial ssh login environment to get created, but not allow users to manually execute login for a local login. OR Edit /etc/login.access to disallow LOCAL logins for users. How-To-Repeat: Simple- (login via ssh, login locally from shell using 'login', exit, w or who) Detailed- Log in via ssh to a normal user shell. Type date and note the time. Run w or who to verify user is listed. Wait at least one minute. Type login and log in with same username. Type date and note the new time. Run w or who to verify user is still listed. Wait at least one minute. Type exit. Type date and note the third time. Run w or who - user is no longer listed. user count is incorrect. Run last (username). This will show (user) logged out at the same time (user) logs in with the 'login' command.
Brandon, I'm unable to recreate your problem on a 6.2-R and a 7.0 box. Current behavior is now like you're describing good behavior: the first shell will get closed as soon as the 2nd one is exited. I'm wondering if you're still able to see the problem or if we can close this PR?
State Changed From-To: open->feedback request confirmation from submitter to close
State Changed From-To: feedback->closed mail to submitter bounces with "no route to host" -> closing this note to submitter: If you see this message and think it's still an issue you're seeing, please provide us with a valid email address and we'll reopen this ticket.
This still happens on a 7.0 machine, but not when the shell is /bin/csh or /bin/tcsh - if a csh is used then the first shell is closed when the 2nd login is exited. If you use /bin/sh then the following is seen: > ssh box1 Password: $ w 10:21AM up 6 days, 10:56, 1 user, load averages: 0.01, 0.02, 0.00 USER TTY FROM LOGIN@ IDLE WHAT user1 p0 abcd:aaa:aaa:a:b 10:21AM - w $ login login: user1 $ w 10:22AM up 6 days, 10:57, 1 user, load averages: 0.00, 0.01, 0.00 USER TTY FROM LOGIN@ IDLE WHAT user1 p0 - 10:22AM - w $ exit $ w 10:22AM up 6 days, 10:57, 0 users, load averages: 0.00, 0.01, 0.00 USER TTY FROM LOGIN@ IDLE WHAT $ exit Connection to box1 closed. > -- Bruce
State Changed From-To: closed->open reopen as requested - still an issue as confirmed by Bruce submitter: if you see this, please give us a valid email address if you're still interested in this issue.
I am experiencing the same problem. I am happy to provide more detail if required. The "at" command sends an email with the output of the scheduled job. I've experienced inconsistent results when running jobs, receiving emails in accounts not associated with the user currently logged in. To reproduce in FreeBSD 7.2-RELEASE-p2 Case #1 login as user a (new shell through ssh) echo "echo 1" | at now --> user a will receive an email containing "1" - this is as expected Case #2 login as user a (new shell through ssh) login as user b exit echo "echo 1" | at now --> user b will receive an email containing "1" - this is not as expected, since I am user a again A look at the source for "at" reveals that "at" is getting the mailname from getlogin(). Running a small test program that outputs getlogin(), confirms the above behavior: A log-in and out of another account makes getlogin() return that account's name, even though the shell has been closed and we are back to the original shell and the original user a. Holger
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped