fedora-silverblue / issue-tracker

Fedora Silverblue issue tracker
https://fedoraproject.org/atomic-desktops/silverblue/
122 stars 3 forks source link

When layering at package, at commands fail #563

Closed rrenomeron closed 6 months ago

rrenomeron commented 6 months ago

This issue tracker is intended only for Silverblue specific issues. We would like to ask you to try to reproduce the issue on a relevant Fedora Workstation release. If you will be able to reproduce there, then please report it in Red Hat Bugzilla (see How to file a bug) or in upstream (preferred for GNOME projects) and not in this issue tracker.

Describe the bug After layering the at package and rebooting, any attempt to run the at command results in the following error:

warning: commands will be executed using /bin/sh
Cannot open lockfile /var/spool/at/.SEQ: No such file or directory

To Reproduce Please describe the steps needed to reproduce the bug:

  1. Install at with rpm-ostree install at
  2. Reboot
  3. Open terminal
  4. Run at 21:00

Expected behavior An at> prompt for entering commands

warning: commands will be executed using /bin/sh
at Sat May 18 22:00:00 2024
at> 

Screenshots N/A

OS version:

State: idle
BootedDeployment:
● fedora:fedora/39/x86_64/silverblue
                  Version: 39.20240519.0 (2024-05-19T01:00:12Z)
               BaseCommit: 26fa4886e8496694890e1e8b6d7929fac418c6a9dd7f7b814db01772d12a4fe3
             GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
          LayeredPackages: at

Additional context Adding the file fixes the problem.

I also see a similar issue on Universal Blue/Bluefin/Custom Images (where I have put the at package in the container image), but with those, the entire /var/spool/at directory tree is missing (for whatever that is worth).

miabbott commented 6 months ago

I think this related to the packaging of the at RPM; specifically the package has a %post section that touches the /var/spool/at/.SEQ file and sets permissions on it.

https://src.fedoraproject.org/rpms/at/blob/rawhide/f/at.spec#_122-125

The state of /var isn't tracked as part of the ostree commit, so these actions will be discarded/ignored after rebooting into the new deployment.

The packaging should be changed to use systemd tmpfiles.d. For example, see how the cups package handles the creation of files under /var/spool/cups

https://src.fedoraproject.org/rpms/cups/blob/rawhide/f/cups.spec#_461-468

I'd recommend filing an issue with the at packaging in Fedora: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=at

travier commented 6 months ago

+1 to what Micah said.

Alternatively, you can install and run this from a toolbox container or use systemd timer unit which are a better superset of this functionality.