Systemd[921]: Failed to start Comodo Antivirus

The thing is, I never installed comodo antivirus… There was no need for it. As far I know, it’s not in the system, because I can’t see anything related to “comodo”, nor “antivirus” on the installed packages list, and have no idea why this error showed up.

Then why journal logs show me this error?

systemd[921]: Failed to start Comodo Antivirus

I know it’s a harmless error, but I would like to clean it up, if possible.


You could check the paths where units are started from, to see if there is a service definition lingering around that has “Comodo Antivirus” in it’s description line…
Maybe a recursive grep :wink:

1 Like

Thanks, but it looks like the documentation you send me is a bit outdated or over my head.

There are too many paths and most of them don’t even exist on my system, like:


I will continue reading the given article, and maybe I will figure this out, but it’s a lot to take in.

Yes those paths are searched for “if they exist” so not all have to exist :wink:

You just need to focus on the paths it mentions, for your problem.
The rest is just info about unit files etc which you don’t need to learn at moment…

The same info as on that page, can be accessed using man systemd.unit :wink:
(Especially handy to copy/paste the paths you want to search in)

1 Like

I going through possible paths and so far didn’t find anything related to comodo or antivirus. However, I noticed:


I uninstalled foldingathome app 2 years ago, so why there is still systemd unit for it? Can I safely remove it by removing the folder? Or maybe will it break something, because the path to that folder is somewhere else as well?

It’s anyway inactive and dead.

So basically, how to remove it safely? I bet that the answer is somewhere in this article. I recall deleting some systemd services in the past, but I don’t recall details, so I prefer to ask, if you know the answer from the top of your head.

That is actually a directory and not a system unit on it’s own.
Directories like that (ending in .d are used to place “drop-in” files to override settings of the unit file (without the .d extension)
So if there is no foldingathome.service anywhere in your system, you could safely remove that directory and it’s contents if you’re sure you won’t be needing it again in future…
To make sure you can use one of or both of:

  1. systemctl status foldingathome
  2. systemctl cat foldingathome
    This last one will show all files involved with that unit.

Make sure to grep for that text inside the unit files, and not just look at filenames…

I get conflicting data on that one. When using commands as you showed me, I get nothing:

Unit foldingathome.service could not be found.
No files found for foldingathome.service.

However, in Plasma systemd settings I do see:

Also, the folder is not empty. It contains override.conf

However, I’m sure I won’t be needing it. This was clearly automatically added by foldingathome app, or maybe it was added manually after following install instruction? I don’t recall that now. This isn’t needed by anything else on the computer and is specific to that app, which I won’t be using anyway.

More close on-topic, Plasma doesn’t see any unit for comodo or antivirus. I also can’t find it, so I still don’t know where it is hidden.

Can it be, that the unit for comodo anitvirus doesn’t exist but is still requested by something else, hence the error?

Yes that’s as expected as i explained already :wink:

I don’t speak polish so i can’t say what your screenshot shows.
But i do see the “not found” at start of that line, which is strange indeed…
Maybe it is tried to be pulled-in by some other unit’s dependency, system or user unit no idea…

Please also take note that the command line versions will show you the definitive answer, the GUI might be using an outdated cache :thinking:

But the files inside the folder would suggest that the GUI is right after all:

Found some info about deleting services:

Hm… Will look into it.

EDIT: About the GUI, I marked “Show inactive” and “Show removed from the memory”. The not-found is the “Loaded state” column.

I could always do an experiment: I would rename the folder to foldingathome.service.d.bak and see if it still shows or if it generates errors.

However, I still have no clues about comodo antivirus.

This may be the case with comodo antivirus. In such case, how to look for it?

EDIT2: Found some better info about removing/adding systemd services:

As i told in reply #2, that’s the only way to find which unit has “Comodo Antivirus” as description because that is used in the log line you mentioned…
Once you find that unit you can start checking the dependencies of said unit, to see who is interacting with it…

Maybe check the log lines before and after that log line you mentioned to see clues that are related to it…

I didn’t get how to do that. Where is this “description” and how to look for it?

It is one of the keys used in a unit file, so you need to use grep to find contents inside the unit files.
It looks like:


See that man page i linked to and mentioned…

Example usage of grep:

grep --recursive --extended-regexp '.*Comodo.*' /etc/systemd/system
grep -rE '.*Comodo.*' /etc/systemd/system

These are same :wink:

Edit: fixed the regExp :smiling_face:

1 Like

That was what I was just about to ask. Thanks! However, I get:

grep: attention: * is on the beginning of the regular expression

And then nothing. Does it mean that the result of search is nothing and the above is just a warning in case this wasn’t what I wanted?

So basically it looked for me like that:

 michaldybczak  alienware-PC  ~  sudo grep --recursive -E '*Comodo*' /etc/systemd/system
[sudo] password user michaldybczak: 
grep: attention: * is on the beginning of the regular expression

That’s very strange i don’t get that :thinking:
You can also try without the * i guess :woman_shrugging:

Is it cap sensitive? I’m testing it on “fah” that I know it exists in this foldingathome service.
Different from “Comodo”, this time the search takes a long time to complete. I’m waiting for 2-3 mintues and it’s still running:

sudo grep --recursive -E '*fah*'/etc/systemd/system

It is normal to take some time, but i think you forgot a space between the path and the expression :wink:
(So now it wait for input from you at the terminal)

For case-sensitivity and all other options please see man grep :wink:

1 Like

If you want to use -E or --extended-regexp you need to use real regular expressions. For example

grep -rE '.*Comodo.*' /etc/systemd/system

If you just want to use bash glob patterns don’t use the -E

It is not that slow.


1 Like

You are soo right :rofl:
Still weird it didn’t gave me the same message, but yes those dots are crucial for the regExp…

Maybe you use a alias for grep with other options.

Sometimes it helps to try it with

\grep -rE '*Comodo*' /etc/systemd/system

Yes that is exactly my personal case…

alias grep='grep --color=auto --initial-tab --line-number'

I even tried using command infront to bypass the alias version.
Ahh well, lets not derail the OP with my personal details…

1 Like