cleanup-service

[Dreick-dev]

I'm not sure but is the cleanup-service intended to get activated by hand? There is no hint do do so at installation, as far as I remember. Today I tried to figure out why my root-partition got bigger and bigger and analyzed it with filelight. This is what i got:

When I looked into named modules directory I saw what it was:

I looked into this repo and saw, that a system-service was intended to cleanup on startup. I looked for it, and saw, that it was not enabled. I triggered it by hand and of course, it took an eternity to copy - delete - copy -delete... and finally delete all copied directories.

Am I the only one who took that long to notice that? Either way, maybe it would be cool if the PKGBUILD could echo a hint to the console to activate the service.

Not a high-priority thing, but maybe a funny story and a suggestion.

[saber-nyan]

It seems that the file kernel-modules-hook.install was not added to the community repo when the package was added, so users do not see request to enable the systemd service linux-modules-cleanup.

kernel-modules-hook/kernel-modules-hook.install

Lines 1 to 16 in d5bb3c3

	post_install() {
	cat << EOF
	Please execute
	$ sudo systemctl daemon-reload
	$ sudo systemctl enable linux-modules-cleanup
	Report any issues to:
	https://github.com/saber-nyan/kernel-modules-hook/issues
	~desu
	EOF
	}

@shibumi is it possible to enable this service when installing the package or to notify the user to enable it?

[thurstylark]

FWIW, the daemon-reload instruction is superfluous in light of the systemd-daemon-reload hook that's shipped with the systemd package.

But otherwise, yes, the package as it exists in community currently lacks a notification that enabling the cleanup service is necessary for the advertised cleanup functionality to ...function.

I doubt that enabling or starting the systemd unit on install will be possible, as that's usually considered a user's choice to make, but it might be possible to get an install script notification added to the package.

I've created a feature request with downstream to float this idea, so we'll see how that goes: https://bugs.archlinux.org/task/74592

[C0rn3j]

@saber-nyan Please also add the instructions to the README

https://github.com/saber-nyan/kernel-modules-hook#installation

[KAGEYAM4]

kernel-modules-hook/linux-modules-cleanup.service

Line 6 in d5bb3c3

ExecStart=/bin/bash -exc 'for i in /usr/lib/modules/[0-9]*; do if [[ $${i##*/} = \'%v\' ]] || pacman -Qo "$${i}"; then continue; fi; rsync -AHXal "$${i}" /usr/lib/modules/.old/; rm -rf "$${i}"; done'

About the cleanup.service. why is it performing rsync to .old directory. Who is suppose to clean that?

Also what is the use of https://github.com/saber-nyan/kernel-modules-hook/blob/master/linux-modules-cleanup.conf, i read pre-hook, post-hook and cleanup.service. No one seems to be using this file.

[C0rn3j]

No one seems to be using this file.

It's in the PKGBUILD. It goes to tmpfiles.

Who is supposed to clean that?

The file you've just asked about, I imagine.

[KAGEYAM4]

@C0rn3j Thanks. Didn't knew this usecase of /usr/lib/tmpfiles.d/.

By the way all this copying back and forth (3 times - pre,post,.old). Does it increases Writes on SSDs? Or is BTRFS only copying refrences and not actually copying the whole data again and again with every rsync operation.

[C0rn3j]

Does it increases Writes on SSDs?

Probably. Why don't you check?

Your SSD won't explode if you write files to it, it was made for it.

Kill tests of even ancient tiny SSDs went into petabytes, stop worrying.

[WaleedMortaja]

I think it is a sensible choice to have it enabled by default, but should be also started while the upgrade is going on instead of on next reboot (because it may take a long time, and people can assume longer time during the upgrade rather than a long time on the first next boot).

Anyway, The downstream issue has been moved to a gitlab issue but there is no any interaction since then?

[dnut]

This hook runs automatically by default once installed, so the service should also be automatically enabled once installed. It's the only consistent way to install the package. Printing a message for the user is not sufficient.

Better yet, the cleanup should be a hook. I don't see why a service is needed for this.

[shibumi]

@shibumi is it possible to enable this service when installing the package or to notify the user to enable it?

The default policy in Arch Linux is that we do not automatically enable services. We are not Ubuntu 😛

[dnut]

The default policy in Arch Linux is that we do not automatically enable services. We are not Ubuntu 😛

This is a good policy in general, but it becomes inconsistent if the same policy is not applied to pacman hooks. Also, the policy should include an exception for when it would be actively harmful to install a package without activating its service.

Pacman hooks are automatic behaviors triggered upon installation, much like services. If services must be explicitly enabled by the user, then hooks should follow the same rule. Allowing one but not the other creates a contradiction in policy.

This inconsistency is already causing real problems for users.

There are only two coherent solutions to this problem:

• Neither is enabled automatically.
• Both are enabled automatically.

Enabling both is obviously more practical for this package, so the policy should be amended to permit cases like this.