Hi. I’m new to Fedora and I am looking for some assistance. I decided to install Fedora 33 beta this past weekend and ran into a few issues. This post is for only one of the issues.
After installation, I created my daily backup to utilize rsync and systemd units as I have with my past distro. Once I finished creating the script and unit files, I verified and received several warnings that I am not familiar with. The script is fine. The warnings are with the units and are listed here: https://hastebin.net/xukekahila.rs
Create bash script
$ sudo nano /opt/mybackup.sh
$ sudo chmod +x /opt/mybackup.sh
Create service unit
$ sudo nano /etc/systemd/system/mybackup.service
Service unit file
Description=Daily backup using rsync
$ sudo systemctl daemon-reload
$ sudo systemctl start mybackup.service
Create timer unit
$ sudo nano /etc/systemd/system/mybackup.timer
Timer unit file
Description=Daily backup of home directory
$ sudo systemctl start mybackukp.timer
$ sudo systemctl enable mybackup.timer
$ sudo systemd-analyze verify /etc/systemd/system/mybackup.*
The verification returned a list of warnings around plymouth-start.service. I have a basic understanding of the unit files but know nothing about plymouth. It referred to KillMode=none but I have not used that parameter. I can only assume that there must something implied that I am not understanding or missing.
Any help deciphering the warnings would be much appreciated. Thanks!
EDIT: I forgot to include the details of the unit files.
Those warnings do not appear to be related to your service files, rather they are caused by system unit files (related to the boot splash screen, initrd and sound). It looks like the newer systemd version included in F33 has deprecated a few options that are still in use by those units.
You can file bugs against those components on buzilla.redhat.com (check if someone else has reported them already before you do) to let the maintainers know they should adapt their unit files.
Thank you for your reply and assistance. It is greatly appreciated. I will submit a bug report.
I found information on KillMode here freedesktop.org and here man7.org. Each recommends not using
KillMode=none . Should I add something like
KillMode=mixed to my service unit to override the implied
KillMode=none parameter, or does KillMode simply not pertain to anything I am attempting to do here? The documentation leads me to believe that it applies to all systemd units but it may be that user created units are excluded.
What I find odd, or confusing, is that running the verification
$ sudo systemd-analyze verify /etc/systemd/system/mybackup.* only returns these warnings when my unit files are present. When I remove those files and run the verification, no warnings return. That is expected because the filepath I am verifying no longer exists. However, how does the verification catch
/usr/lib/systemd/system/plymouth-start.service when my verification command does not include that path? Or is that is a part of the bug?
systemd-analyze verify also loads any units mentioned in the unit file being analysed, and looks for them in the path given and in the default path, which is
/usr/lib/systemd/. I don’t know exactly how it does that, but since the services throwing warnings are all pretty low-level system services I guess it tests the full stack that leads to your unit, i.e. they’re pulled in via
timers.target. They’re unrelated to your unit, they just happen to be part of a system capable of running a timer unit.
KillMode=none only applies to the plymouth service:
% cat /usr/lib/systemd/system/plymouth-start.service
Description=Show Plymouth Boot Screen
That should be fixed in the plymouth package, but doesn’t impact your units.
Got it. Thanks! I suppose what threw me off was not expecting how
systemd-analyze verify loads more than the path I included.
I submitted a bug report for the plymouth-start.service warning [Bug 1889923]. There was already a bug report covering the dracut warnings [Bug 1873286].
Thanks again and have a great day.
You’re welcome. Thanks for opening the bug report, that is always very helpful to maintainers.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.