1

I came across the messages below with sudo journalctl --since today | tail -n 3000. Shouldn't autostart entries be removed from there when removing a package?

It seems like general good practice to remove autostart entries if the package has been removed (or to prompt the user about it during removal or to remove them when running a command like sudo apt-get autoremove). Moreover, wouldn't it cause executables to get autostarted if they are named / aliased / linked in the same way the command in Exec there.

If this isn't currently done, what would be the right way to auto-remove these entries? Where could an issue about this exist? For now I under Debian12/KDE just moved them like so sudo mv /etc/xdg/autostart/xbindkeys.desktop ~/DisabledAutostarts_defunct/xbindkeys.desktop and hope that is fine as is as a workaround.

systemd-xdg-autostart-generator[1712]: Exec binary 'xbindkeys_autostart' does not exist: No such file or directory systemd-xdg-autostart-generator[1712]: /etc/xdg/autostart/xbindkeys.desktop: not generating unit, executable specified in Exec= does not exist. systemd-xdg-autostart-generator[1712]: Exec binary '/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1' does not exist: No such file or directory systemd-xdg-autostart-generator[1712]: /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop: not generating unit, executable specified in Exec= does not exist. systemd-xdg-autostart-generator[1712]: Exec binary 'gsettings-data-convert' does not exist: No such file or directory systemd-xdg-autostart-generator[1712]: /etc/xdg/autostart/gsettings-data-convert.desktop: not generating unit, executable specified in Exec= does not exist. systemd-xdg-autostart-generator[1712]: Exec binary 'start-pulseaudio-x11' does not exist: No such file or directory systemd-xdg-autostart-generator[1712]: /etc/xdg/autostart/pulseaudio.desktop: not generating unit, executable specified in Exec= does not exist. systemd-xdg-autostart-generator[1712]: Exec binary 'kmixctrl' does not exist: No such file or directory systemd-xdg-autostart-generator[1712]: /etc/xdg/autostart/restore_kmix_volumes.desktop: not generating unit, executable specified in Exec= does not exist. systemd-xdg-autostart-generator[1712]: Exec binary 'kmix' does not exist: No such file or directory systemd-xdg-autostart-generator[1712]: /etc/xdg/autostart/kmix_autostart.desktop: not generating unit, executable specified in Exec= does not exist. systemd-xdg-autostart-generator[1712]: Exec binary 'usbguard-applet-qt' does not exist: No such file or directory systemd-xdg-autostart-generator[1712]: /etc/xdg/autostart/usbguard-applet-qt.desktop: not generating unit, executable specified in Exec= does not exist.

Files that cause things to autostart are different from any /etc/ config file which just provides some configs if the application is running. In addition to the problem mention, it can for example even also be a problem when reinstalling a later version of the same software because it could create an additional entry in that folder with another name so it starts twice. Issue is here now.

Improve this question

1 Answer 1

Reset to default
2

These files are treated as configuration files, and are only removed on package purge, not package removal.

apt list '~c'

will list packages which have been removed but not purged (including potentially some which dpkg still considered to be installed but which aren’t really).

sudo apt purge '~c'

will purge them, and you’ll see their configuration files in /etc disappear too.

I agree that this situation isn’t great. I think the best solution would be if the Desktop Application Autostart specification allows autostart files to be dropped somewhere under /usr (in the same way as regular .desktop files can be installed in /usr/share/applications); that way packages could ship their default autostart files there, and they would be removed automatically along with the other non-configuration contents.

Improve this answer
4
  • Here is a command to remove all of them. I still think the autostart entries should be purged without specifying that option or that the user should be prompted about that when removing a package. Commented Apr 8, 2024 at 11:02
  • With the creation of the issue linked at the bottom, I'm marking this as the solution. I don't think changing the the autostart items folder would be a better than removing it from there but alternatives like that can be suggested there. Commented Apr 10, 2024 at 18:39
  • 1
    The reason I suggested moving the autostart files (in the package) is that files under /usr aren’t handled as configuration files, and are removed as part of the package contents in all package removal operations (whether plain remove or purge). That would avoid the issue entirely. Commented Apr 11, 2024 at 21:05
  • Yes it does make sense and sadly that's also what the first and closing reply to the bug report pointed to. The only problem I have with that is that to me it doesn't seem like a realistic option: putting files into that /etc directory is pretty established now (for example checking Autostart in the app Vorta adds a file there) and I thought it would be more feasible that files of this specific /etc folder are deleted or moved when removing a package than the autostart registration directory be changed. But would be great if I was proven wrong on that. Commented Apr 11, 2024 at 21:59

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.