Bug 1956392 - Failed to parse system call, ignoring:
Summary: Failed to parse system call, ignoring:
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: arpwatch
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ben Beasley
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-03 15:33 UTC by Villy Kruse
Modified: 2021-05-12 05:43 UTC (History)
1 user (show)

Fixed In Version: arpwatch-3.1-13.fc34
Clone Of:
Environment:
Last Closed: 2021-05-12 05:43:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Villy Kruse 2021-05-03 15:33:35 UTC
Description of problem:

Found this in journal log at warning level

May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@aio
May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@chown
May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@clock
May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@ipc
May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@keyring
May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@memlock
May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@resources
May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@sync
May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@timer



Version-Release number of selected component (if applicable):

arpwatch-3.1-12.fc34.x86_64

Comment 1 Ben Beasley 2021-05-03 17:11:04 UTC
Thanks. It looks like my downstream sandboxing configuration in the service file is not quite tailored to the current version of systemd. I’ll look into it shortly.

Comment 2 Villy Kruse 2021-05-04 05:55:57 UTC
Maybe you need to separate the allow list and the deny list in this way:

SystemCallFilter=@system-service
SystemCallFilter=~@aio @chown @clock @ipc @keyring @memlock @resources @sync @timer


The manual systemd.exec says:
 "If the first character of the list is "~", the effect is inverted"

That is the "~" is the first character after "=" and applies to the entire list.

You might want to ask the systemd developers if this is true.

Comment 3 Ben Beasley 2021-05-04 12:50:42 UTC
That’s what I concluded yesterday, too. Based on documentation, and validated by testing, I arrived at the same syntax you suggested. I hadn’t gotten the update pushed for Fedora 34 yet, though. I’ll do that next.

Thanks again for your very helpful feedback.

Comment 4 Fedora Update System 2021-05-04 12:53:19 UTC
FEDORA-2021-65cde10eeb has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-65cde10eeb

Comment 5 Fedora Update System 2021-05-05 01:51:03 UTC
FEDORA-2021-65cde10eeb has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-65cde10eeb`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-65cde10eeb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Fedora Update System 2021-05-12 05:43:06 UTC
FEDORA-2021-65cde10eeb has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


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