Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#61700 - [at] atd: Authentication failure, missing pam.d policy

Attached to Project: Community Packages
Opened by Klaus Alexander Seistrup (kseistrup) - Sunday, 10 February 2019, 11:17 GMT
Last edited by Christian Hesse (eworm) - Wednesday, 20 February 2019, 17:39 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No



atd logs “Authentication failure” for every at job (and the actual job is not run at all).

This happens after the latest PAM update a couple of days ago.

I'm unsure if there has ever been an /etc/pam.d/atd file, but there isn't one now. Copying the existing /etc/pam.d/crond file to /etc/pam.d/atd makes atd work like expected. Attached as pam.conf.

Additional info:
* package version(s): 3.1.23-1

Steps to reproduce:

1. start atd: sudo systemctl atd.service
2. submit a batch job: echo date | at now
3. find “atd[$PID]: Authentication failure” in syslog
4. /var/log/auth.log may show something like "atd[$PID]: pam_warn(atd:account): function=[pam_sm_acct_mgmt] flags=0x8000 service=[atd] terminal=[<unknown>] user=[$USER] ruser=[<unknown>] rhost=[<unknown>]
   pam.conf (0.3 KiB)
This task depends upon

Closed by  Christian Hesse (eworm)
Wednesday, 20 February 2019, 17:39 GMT
Reason for closing:  Fixed
Additional comments about closing:  at 3.1.23-2
Comment by Robin Becker (replabrobin) - Sunday, 10 February 2019, 13:50 GMT
I can confirm this is an issue; sudo cp /etc/pam.d/crond /etc/pam.d/atd also works for me.
Comment by Klaus Alexander Seistrup (kseistrup) - Sunday, 10 February 2019, 15:09 GMT
I would like to state at this time that PAM is new territory for me: I do not know what a sensible /etc/pam.d/atd file looks like, I merely thought that since crond and atd are working in the same realms it might be worth trying crond's PAM file with atd – and save for the fact that Debian's PAM structure is somewhat different than Arch's, the crond PAM file for ArchLinux doesn't seem to be functionally different from Debian's atd PAM file.
Comment by Klaus Alexander Seistrup (kseistrup) - Sunday, 10 February 2019, 16:38 GMT
See also  FS#61704  - xlockmore needs a pam file
Comment by Ralph Corderoy (RalphCorderoy) - Monday, 11 February 2019, 12:48 GMT
I can confirm this too. (Can the status be changed to Confirmed.)
It's not apparent to the user that the jobs didn't run successfully,
and this can cause all sorts of knock-on issues.
Comment by Ralph Corderoy (RalphCorderoy) - Monday, 11 February 2019, 13:22 GMT
I think the impact is data loss.
On initial investigation, /var/spool/atd contained the /bin/sh scripts to be run in the future, and pairs of `a' and `=' files, e.g. a03894018a25e0 and =03894018a25e0. Normally, the first would contain the /bin/sh, but it instead has the start of the email to send on capturing the command's output.

Subject: Output from your job 14484
To: ralph

The `=' had the /bin/sh script. On restarting atd, all the =* are deleted. The a* remain, but all of them are the email's header lines with no body; any output has been lost. The original, one-off, script to run has been lost.

atq(1) shows the emails as entries in the queue with their correct dates and times; now in the past.
Comment by Eli Schwartz (eschwartz) - Wednesday, 20 February 2019, 17:36 GMT
sources contain the file "pam.conf", which is not installed by the build system. On the other hand, despite claims in the ChangeLog that: "Copy debian/pam to pam.conf, it's not Debian-specific." -- it is indeed debian-specific, as it uses Debian's

@include common-auth
@include common-account
@include common-session-noninteractive

none of which exist on Arch.