Bug 1956392 - Failed to parse system call, ignoring:
Summary: Failed to parse system call, ignoring:
Keywords:
Status: ON_QA
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-05 01:51 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


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.


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