Bug 812151 - The "at" command is killed very quickly
Summary: The "at" command is killed very quickly
Keywords:
Status: CLOSED DUPLICATE of bug 812682
Alias: None
Product: Fedora
Classification: Fedora
Component: at
Version: 17
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Marcela Mašláňová
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-12 21:53 UTC by Göran Uddeborg
Modified: 2012-04-17 16:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-17 14:44:52 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
strace of "at" (377.51 KB, text/plain)
2012-04-12 21:54 UTC, Göran Uddeborg
no flags Details
strace of "systemd-logind" (12.54 KB, text/plain)
2012-04-12 21:55 UTC, Göran Uddeborg
no flags Details

Description Göran Uddeborg 2012-04-12 21:53:31 UTC
Description of problem:
I'm gradually migrating to F17.  I've done the usrmove operation, and am upgrading package by package.  Today I noticed that the "at" command no longer worked.  Not while loading.  Some of the time it can print some of the queued jobs when I do "at -l".  But it dies pretty quickly, and the shell says it is "Terminated".

I've tried to investigate what is happening, and have come to the conclusion the systemd-logind process is sending the SIGTERM.  From what I understand, systemd-logind believe the session is finished, and kills the remaining process in it.  But I don't understand systemd enough to understand exactly WHY it believes the session is done before the command is finished, and if systemd or at is doing something wrong.  (Nor why running "at" is considered a session of its own in the first place.)

In /var/log/messages, these three lines show up:

Apr 12 23:40:03 freddi at: PAM pam_close_session: NULL pam handle passed
Apr 12 23:40:03 freddi systemd-logind[588]: New session 9 of user göran.
Apr 12 23:40:03 freddi systemd-logind[588]: Removed session 9.

I'll attach strace:es of the at command, as well as of systemd-logind during the period the command was run.  It clearly shows the kill() calls done byt systemd-logind just before at dies.  I traced atd too, but it didn't do anything, so I guess it wasn't involved.

I'm not sure if this is a bug in at, in systemd, in the order I'm upgrading things, or simply something I've messed up.  I know upgrading piece by piece isn't the supported way, but I do believe I've upgraded all packages involved here.


Version-Release number of selected component (if applicable):
at-3.1.13-7.fc17.x86_64
systemd-44-4.fc17.x86_64
pam-1.1.5-5.fc17.x86_64
pam-1.1.5-5.fc17.i686
glibc-2.15-32.fc17.x86_64
glibc-2.15-32.fc17.i686


How reproducible:
Every time, with a slight variation on HOW fast the command dies.  Doing "at -l" produces SOME output SOME of the time, before it dies.

Steps to Reproduce:
1. Run "at teatime"
  
Actual results:
A line "Terminated" and a new shell prompt.

Expected results:
A prompt from "at" waiting for input.

Comment 1 Göran Uddeborg 2012-04-12 21:54:28 UTC
Created attachment 577177 [details]
strace of "at"

Comment 2 Göran Uddeborg 2012-04-12 21:55:42 UTC
Created attachment 577179 [details]
strace of "systemd-logind"

This trace was started just before staring "at", and stopped just after it died.

Comment 3 Marcela Mašláňová 2012-04-13 08:58:38 UTC
Wow, thanks for report. I'll look at it.

Comment 4 Marcela Mašláňová 2012-04-17 14:30:04 UTC
Hm, I can't reproduce it as a root. Could you? I see it only as regular user. It looks like duplicate of 812682.

Comment 5 Marcela Mašláňová 2012-04-17 14:44:52 UTC

*** This bug has been marked as a duplicate of bug 812682 ***

Comment 6 Göran Uddeborg 2012-04-17 16:06:01 UTC
> Hm, I can't reproduce it as a root. Could you?

I hadn't tried as root.  You are right, it doesn't happen to root.


Note You need to log in before you can comment on or make changes to this bug.