Bug 1956392

Summary:	Failed to parse system call, ignoring:
Product:	[Fedora] Fedora	Reporter:	Villy Kruse <ppywlkiqletw>
Component:	arpwatch	Assignee:	Ben Beasley <code>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	34	CC:	code
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	arpwatch-3.1-13.fc34	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-05-12 05:43:06 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:

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.