Noob question : how to troubleshoot systemd phantom UNIT?

The issue

straight from sudo journalctl -p 3 -xb

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:
░░ 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:
░░ 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:

  • /usr/lib/systemd/system
  • /usr/lib/systemd/user
cat /usr/lib/systemd/user/app-org.kde.spectacle.service
File: /usr/lib/systemd/user/app-org.kde.spectacle.service
Description=Spectacle screenshot capture utility

ExecStart=/usr/bin/spectacle --dbus

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.

Generally you shouldn’t touch the files in that location. That is not the only location systemd looks for.

For system units, you should check /etc/systemd/system. If you want to modify unit files, that is where you should put them.

If you have accidentally deleted files, you should reinstall the packages to bring those service files back.

Also, make sure those aren’t user services. User services are in different locations. See here for details:


Thanks for the suggestion @dalto ! I’ll go there and study, then I’ll trace down the involved packages to bring the service files back.

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\[email protected]


Description=Initial Bashrc setup

ExecStart=:/usr/bin/mv /home/alpha/.bashrc_garuda "/home/alpha/.bashrc;" rm /home/alpha/.config/autostart/bashrc-setup.desktop

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\[email protected])

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

and it goes by the name of
app-snapper\x2dtools\[email protected]

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.

You can check that for all packages in your system at once.

sudo paccheck --list-broken

If any package has missing files, it will be printed out.



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

Therefore I appended


to the .desktop file under /etc/xdg/autostart/snapper-tools-check.desktop…and now Systemd is not attempting to start the service anymore.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.