This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 812151 - The "at" command is killed very quickly
The "at" command is killed very quickly
Status: CLOSED DUPLICATE of bug 812682
Product: Fedora
Classification: Fedora
Component: at (Show other bugs)
17
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-12 17:53 EDT by Göran Uddeborg
Modified: 2012-04-17 12:06 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-17 10:44:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Göran Uddeborg 2012-04-12 17:53:31 EDT
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 17:54:28 EDT
Created attachment 577177 [details]
strace of "at"
Comment 2 Göran Uddeborg 2012-04-12 17:55:42 EDT
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 04:58:38 EDT
Wow, thanks for report. I'll look at it.
Comment 4 Marcela Mašláňová 2012-04-17 10:30:04 EDT
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 10:44:52 EDT

*** This bug has been marked as a duplicate of bug 812682 ***
Comment 6 Göran Uddeborg 2012-04-17 12:06:01 EDT
> 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.