Remove stale 99-omarchy-nofile.conf drop-ins via migration#6173
Conversation
The 99-omarchy-nofile.conf drop-ins used `DefaultLimitNOFILESoft`, which is not a valid systemd [Manager] setting. systemd rejects it at manager load on every boot: /etc/systemd/system.conf.d/99-omarchy-nofile.conf: Unknown key 'DefaultLimitNOFILESoft' in section [Manager], ignoring. They were superseded by 20-omarchy-nofile.conf (which correctly uses `DefaultLimitNOFILE=65536:524288`), but the 99- files are unowned by any package and linger on upgraded systems, spamming the journal every boot. Add a migration that removes the orphaned drop-ins from both system.conf.d and user.conf.d. The 20- drop-in already sets the limit. Co-Authored-By: Claude <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 820306b9a3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| /etc/systemd/system.conf.d/99-omarchy-nofile.conf \ | ||
| /etc/systemd/user.conf.d/99-omarchy-nofile.conf; do | ||
| if [[ -f $f ]]; then | ||
| as_root rm -f "$f" && removed=1 |
There was a problem hiding this comment.
If the privileged rm fails here (for example the user cancels sudo authentication, sudo is unavailable, or one of the two removals errors), Bash does not trigger errexit because the command is on the left side of &&; the script can then exit 0 with the stale file still present. Since bin/omarchy-migrate touches the migration marker immediately after a 0 exit, that user will not be prompted to retry this migration, so the boot-time systemd warning remains permanently until manually fixed.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Pull request overview
This PR adds a per-user migration to clean up orphaned systemd manager drop-ins (99-omarchy-nofile.conf) left behind on upgraded systems, preventing repeated “Unknown key DefaultLimitNOFILESoft” journal noise at boot.
Changes:
- Add a migration that deletes stale
/etc/systemd/{system,user}.conf.d/99-omarchy-nofile.confdrop-ins when present. - Attempt to reload systemd after removal to avoid requiring a reboot.
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| as_root() { | ||
| if (( EUID == 0 )); then | ||
| "$@" | ||
| else | ||
| sudo "$@" | ||
| fi | ||
| } |
| if [[ -f $f ]]; then | ||
| as_root rm -f "$f" && removed=1 | ||
| fi |
| if (( removed )); then | ||
| as_root systemctl daemon-reload >/dev/null 2>&1 || true | ||
| fi |
On upgraded systems,
/etc/systemd/{system,user}.conf.d/99-omarchy-nofile.confremains behind and uses the keyDefaultLimitNOFILESoft, which is not a valid systemd[Manager]setting. systemd rejects it at manager load on every boot:These were superseded by
20-omarchy-nofile.conf(which correctly usesDefaultLimitNOFILE=65536:524288), but the99-files are unowned by any package (pacman -Qoreports no owner), so upgrades never remove them and they keep spamming the journal.Fix
Adds a migration that removes the orphaned
99-drop-ins from bothsystem.conf.danduser.conf.d, then reloads the manager. The20-drop-in already sets the limit, so no functional change to the NOFILE limits.Testing
Observed on a 4.0-alpha (
quattro) system upgraded from an earlier build (14 such errors per boot). After running the migration the errors are gone and20-omarchy-nofile.confcontinues to provide the limit.