Feb 01 10:37:39 kraken systemd[2701]: Failed to start Initial Bashrc setup.
░░ Subject: A start job for unit UNIT has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit UNIT has finished with a failure.
░░
░░ The job identifier is 112 and the job result is failed.
Feb 01 10:37:39 kraken systemd[2701]: Failed to start BTRFS Assistant Snapper check.
░░ Subject: A start job for unit UNIT has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit UNIT has finished with a failure.
░░
░░ The job identifier is 103 and the job result is failed.
Short version (TL;DR)
It looks like there must be some script that invokes Systemd Unit executions at boot time using a generic identifier (UNIT).
Long version (personal lucubrations included)
Is the following possible:
“Initial Bashrc setup” and “BTRFS Assistant Snapper check” get defined as Systemd Units
the long name of the job (i.e. UNIT description) differs from the short name of the Job that for some reason (maybe as a result of another script execution??) gets defaulted to “UNIT” in both cases
for instance, let’s take a valid one (not resulting in error) from one of the following locations:
it’s quite evident how the text in Description is not the same of the .service filename.
So, jumping back to my own errors in journactl I’d say I have two options:
A) identify the malformed or missing .service files (assuming the related user Units are services…) and reintstate them under /usr/lib/systemd/user so that Systemd can finally find them
B) since the related .service files are not there, find the underlying trigger that enrolled
Initial Bashrc setup
BTRFS Assistant Snapper check
and deactivate that…with all related consequences, i.e. bashrc won’t be set (can I leave without it?); the BTRFS check performed by Snapper won’t be executed (this is probably a bad thing?..)
Could you please point me in the right direction?
I’d like to learn how’s this is all structured so that, next time I can troubleshoot on my own.
Thanks in advance for the patience: I know…it’s a noob thing.
Ok.
I managed to heal the Bashrc setup item.
In KDE System Settings - Startup and Shutdown - Autostart there was an application listed that was not recognized (it showed a question mark…)
I removed it and now the error related to the “Initial Bashrc setup” has disappeared.
A very useful utility for hunting: SystemdGenie.
It allowed me to find all the details of the .service file that was located under:
/run/user/1000/systemd/generator.late/app-bashrc\x2dsetup@autostart.service
So all in all I was not that wrong!
The description (Initial Bashrc setup) could not be more different than the .service filename (app-bashrc\x2dsetup@autostart.service)
Given the command invoked (overwriting .bashrc in my user folder with the template file .bashrc_garuda) it is still a mystery to me the reason why it failed to execute…
However: since a) both Terminal and Konsole get initialized as normal and b) both the template and the .bashrc files are there…I decided to kill the autostart item.
The other one (the one related to snapper) is also located under
/run/user/1000/systemd/generator.late/
and it goes by the name of
app-snapper\x2dtools\x2dcheck@autostart.service
For this one I will go down the rabbit hole and check if all the files indicated by Octopi for the snapper-tools package are there.
First things first, thanks again to @dalto : by running paccheck now I now I have the nomachine package corrupted (apparently).
Since it’s not something I’m using on a regular basis, I’ve now removed it.
As a result if I now run again
sudo paccheck --list-broken
I now have a clean slate. (Hurray!)
Coming back to the remaining failing Systemd Unit in autostart, I’ve noticed the following:
It’s not a System Unit but a User Unit → it must depend on a setting configured during a session
by looking into the Unit file it seems that all it does is launching the snapper tool after the logon (it’s an autostart item after all…)
therefore I’d say it has nothing to do with the checks the system might run during the boot sequence BEFORE user session
I believe I can totally live without it.
This consideration led me to subsequent question: how do I disable it?
Both SystemdGenie and systemctl disable seem to be ineffective for the task.
And the reason for this is that the autostart service behind it is handled by systemd-xdg-autostart-generator