Arch Linux

TJM

Member

Registered: 2016-09-18

Posts: 116

Leftover systemd.service drop-in after migration – Best Practices

Hi all,

I recently migrated my Arch system from a ThinkPad to a new HP laptop. As part of the cleanup, I removed the tpacpi-bat package, which provided ThinkPad battery management support, including a systemd unit called tpacpi-bat.service.

However, I noticed that the drop-in override directory still remains: /etc/systemd/system/tpacpi-bat.service.d/override.conf

Since the main unit no longer exists, I'm wondering:

Should I leave this override folder there, or is it better to remove or archive it?

From what I understand, systemd will ignore orphaned drop-in directories unless the unit is explicitly invoked. This will prevent errors or delays at boot, but I'd like to hear what others consider the best practice in this situation.

Here are a few options I've considered:

• Leave it in place – I might reinstall tpacpi-bat someday.

• Move it somewhere else like /etc/systemd/system-archived/ or a dotfiles backup repo.

• Delete it entirely if I'm confident I won't need the package again.

What do you typically do with orphaned override directories after removing packages that used them?

I'd appreciate hearing how others handle this kind of situation. Do you prioritize a clean /etc tree, or do you keep things around just in case?

Thanks in advance!

Last edited by TJM (2025-06-17 09:21:37)

cloverskull

Member

Registered: 2018-09-30

Posts: 243

Re: Leftover systemd.service drop-in after migration – Best Practices

It doesn't hurt anything to leave it there, so if there's a chance you may install tpacpi-bat, I'd just leave it. *shrug*

I never actually noticed this after removing packages myself, but it does seem like it would be a nice feature for pacman to auto clean up (or offer to clean up) these types of artifacts.

lmn

Member

Registered: 2021-05-09

Posts: 79

Re: Leftover systemd.service drop-in after migration – Best Practices

I usually delete old configuration especially if its content is easily reproduced.
If the configuration is more involved I backup the configuration in a git repository for future reference.

One aspect of lingering configuration is that you will forget about it. And it might become (subtly) incompatible with the reinstalled version down the line.
Changes to software configuration should always be explicit especially when it affects the whole system.
Lingering configuration makes implicit assumptions today that might not be true tomorrow.