Firstly, on fedora, both auditd and auditctl come from the same package (unconfusingly named audit). So if you don't have auditctl, something else is wrong. Try this:

rpm -ql audit |grep ctl

If that gives you nothing, then you do not have the audit package installed at all.

Secondly, the first "human" language line in the grub.cfg file you mentioned says "DO NOT EDIT" on my system. This is a clue that any manual changes to the file can be lost.

The correct place to edit the grub config on a fedora/redhat system is the one file you specifically suggested as not being necessary to change (/etc/default/grub). In reality, this is the only "safe" way to make the proposed change and survive kernel upgrades. This is because it is used as part of the source configuration during kernel upgrades, to regenerate a working grub.cfg. Look up the grub2-mkconfig command (and it's friends). Details are here: https://fedoraproject.org/wiki/GRUB_2

Your answer is not wrong, but I found it a little confusing. I hate the grub command line, and IMHO anyone who is likely to miss adding a whitespace char on a kernel command line would probably not thank any one for being lead down that road. Still, some people like to learn the hard way I know.

All commands below need to be run as root (which is in and of itself a dangerous thing to suggest).

For a running system:

auditctl -e 0

If you cannot find auditctl, check your PATH and also consider:

dnf install audit

This should at least reduce if not disable the messages until such a time as you can reboot.

To persist beyond reboots, edit /etc/default/grub and change the GRUB_CMDLINE_LINUX line to add "audit=0" to the end, then use grub2-mkconfig to regenerate the grub.cfg. This final step also puts a layer of validation between your change, and the running system.

After browsing through the manpages few more times (yeah, the answer is never there the first time...), I've come up with a solution... which did not work. After browsing even more, I've finally come up with the most elegant solution possible.

[Unit]
Description=Minecraft server
After=local-fs.target network.target

[Service]
WorkingDirectory=/home/minecraft/minecraft_server
User=minecraft
Group=minecraft
Type=forking
# Run it as a non-root user in a specific directory

ExecStart=/usr/bin/screen -h 1024 -dmS minecraft ./minecraft_server.sh
# I like to keep my commandline to launch it in a separate file
# because sometimes I want to change it or launch it manually
# If it's in the WorkingDirectory, then we can use a relative path

# Send "stop" to the Minecraft server console
ExecStop=/usr/bin/screen -p 0 -S minecraft -X eval 'stuff \"stop\"\015'
# Wait for the PID to die - otherwise it's killed after this command finishes!
ExecStop=/bin/bash -c "while ps -p $MAINPID > /dev/null; do /bin/sleep 1; done"
# Note that absolute paths for all executables are required!

[Install]
WantedBy=multi-user.target

This really does look better than my original script! However, there are a few regressions.

• If I want to pass commands to the server console, then I'll have to make a separate script to do it.
• After running systemctl start minecraft or systemctl stop minecraft, be sure to check systemctl status minecraft, because those commands give no output at all, even if they actually fail. This is the only major regression compared to scripts - "always examine your output" is #1 rule in IT, but systemd doesn't seem to care about it...
• Also, I expected systemd to be able to manage the service shutdown without the "wait for the PID to die" workaround. In the old init script, I had to do this manually, because it was a script, and systemd is trying to eliminate the need for complex scripts that to the same things; it eliminates the need to manually script in all the timeouts and killing whoever did not die, but "waiting for the pid to die" is the next most common thing, and we still need to script it.