Bug 2070858

Summary: at job that does not contain trailing newline gets mangled incorrectly [centos-stream]
Product: Red Hat Enterprise Linux 9 Reporter: Jan Staněk <jstanek>
Component: atAssignee: Jan Staněk <jstanek>
Status: CLOSED ERRATA QA Contact: Jan Houska <jhouska>
Severity: low Docs Contact:
Priority: unspecified    
Version: CentOS StreamCC: bstinson, jhouska, jwboyer, opohorel, rhel-cs-apps-subsystem-qe, sebastiaan
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: at-3.1.23-11.el9 Doc Type: Bug Fix
Doc Text:
Cause: at wraps the job definition (script) in heredoc in order to be able to launch that job in a user's $SHELL. The end marker of the heredoc construct was attached without a newline at the start. Consequence: If the job definition (script) did not end with a newline symbol, the marker would not get recognized as such and the job would be mangled. Fix: The end marker now always include initial newline (it is always added at a dedicated separate line). Result: The marker is now always recognized as a marker and the job is no longer mangled if not ending with a new line.
Story Points: ---
Clone Of: 2070450 Environment:
Last Closed: 2022-11-15 11:15:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2070450    

Description Jan Staněk 2022-04-01 08:33:05 UTC
+++ This bug was initially created as a clone of Bug #2070450 +++

Description of problem:
Scheduling at jobs in python using subprocess does not give expected result.
Somewhere something goes wrong with a `marcinDELIMITER`.


Version-Release number of selected component (if applicable):
- at 3.1.20
- Python 3.6.8


How reproducible:
Very


Steps to Reproduce:
1. open python3 console
2. paste code:
```
import subprocess
p = subprocess.Popen(
    ['/bin/at', 'now'],
    stdin=subprocess.PIPE,
)
stdout, stderr = p.communicate(
    input=b'echo something > test',
)
```

Actual results:
File created named: `testmarcinDELIMITER31aa8a18` with contents: `something`


Expected results:
File created named `test` with contents: `something` 


Additional info:
Running at from the command line works just fine e.g.: `at now <<<'echo something > test'`
Also `input=b'echo something > test\n'` works too.


So my question is this, is this a "bug" in AT, or should python subprocess code always include the newline (\n) character.

--- Additional comment from Jan Staněk on 2022-03-31 09:00:13 UTC ---

Hi, thanks for the report. You are not the only one with that problem, I found this salt issue that seems to stem from the same bug: https://github.com/saltstack/salt/issues/58510
That issue points me to an old at bug#486844. From quick glance, it seems like an at issue (missing newline before the delimiter), but I will have to investigate further.

In the mean time, the suggested workaround is to always include the trailing newline in your Python input field.

--- Additional comment from Jan Staněk on 2022-03-31 09:16:08 UTC ---

This issue is currently present in Fedora 36 Beta too.

Minimal reproducer: `$ echo -n 'touch test.txt'|at now`
Current result: File `test.txtmarcinDELIMITERxxxxxxxx` is touched/created, where `xxxxxxxx` is soime random hexadecimal number (grep basic regex: `marcinDELIMITER[[:xdigit:]]\{8\}$`).
Expected result: File `test.txt` is touched/created.

--- Additional comment from Onmeac on 2022-03-31 12:13:45 UTC ---

> https://github.com/saltstack/salt/issues/58510

Yes that was "us" too, almost a year ago, but that ticket never got anywhere and at the time we had not yet migrated to EL8.

Now we are migrating and in doing so it is becoming more noticeable (in our situation) with using salt.

Thanks for taking the time to investigate this issue.

Comment 9 errata-xmlrpc 2022-11-15 11:15:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (at bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8294