So there are paths that is getting invoked in systemd. I’m guessing %Y, %m & %d also means something in systemd. Explains the path it tried to create in the log file.
Thank you for clarifying that!
Is there any downside keeping the path to the logfile? Kinda enjoy having quarantine and logfiles on those quarantined files in the same dir.
Can I run a command to get stuff into a variable using any of those methods? If I for example wanted to run the date command and save that in a variable I can reuse in the service file?
From systemd man page:
The command line accepts “%” specifiers as described in systemd.unit(5).
I’m going insane here, has that line been the man systemd man page the whole time and my ""¤&%&"¤#! brain could just not see it??? (no need to answer, sometimes I get really pissed at myself)
But then again, asking the question is giving me a TON of extra knowledge. Thank you all!
A systemd unit, a service one in this case, is not a shell environment so you can not exchange environment variable values between the commands.
You CAN however set an environment variable to a fixed value, inside the unit using Environment=, that can be used by all commands in the unit, but no changes to it will be propagated to the others AFAIK.
Each command that you define is a separate process…
Only downside is that the path can not be dynamic.
You don’t need it though. because you can filter the journal in many ways, including the --grep option of journalctl
I suggest you to dig a bit into man journalctl for the MANY ways to filter logs you want.
That’s what I’m looking for, only inside the unit file. I was probably unclear.
But can I set that variable by running the date command, or nesting it in a /usr/bin/bach -c command that applies it to a variable?
I have also seen examples of the usage of: /usr/bin/systemctl set-environment VARIABLE=. Im guessing it is something simular?
I know I know, but basically all I EVER want would be in that logfile, and the location will never change. Besides, the journalctl is still there in CASE that would change.
As already explaind: No…
Every ExecXXXX line invokes a new process that only inherits downwards from the unit’s environment, thus no changes propagate back…
You MIGHT be able to use the EnvoronmentFile directive, who knows, i never tried in this way.
But i advise you to just let go of the dated logfile naming, and use the journal’s time-stamping instead.
OR use a script. to perform that functionality…
You are trying to fit cron possibilities into systemd-units, it’s same as trying the other way, they both have their specialties don’t try to mix.
PS:
As a last resort you ARE able to redirect the stdout of a unit to a file…
Thus you might rename the output file using commands inside the same unit, so the new output will be put inside a new fresh file.
Something working using the utility A, doesn’t mean the same will work in utility B, they both need different approaches to perform similar things.
Sticking to an old habit is not good when you can use newer ways, you might even like the newer way even more as the old way when you get used to it…
To counter your question:
Why are you hesitant to use the journal as logfile/log-medium?
Not sure what you are saying here, but the line: ExecStart=/usr/bin/bash -c '/usr/bin/clamdscan --fdpass --multiscan --move=/home/bedna/.clam/quarantine --log=/home/bedna/.clam/logs/$(date +%%Y-%%m-%%d).log /path/to/backup1/ /path/to/backup2/ 2>/dev/null 1>&2'
works perfectly, naming the logfile with the date placing it in the same dir as the quarantined files (if there are any).
I find no reason changing that unless I find somewhere to make exactly that happen but without the use of date. You mentioned somtheing about systemd-date or somtheing, maybe I will look into that, but I rarely mess with stuff that works.
Edit
I’m not hesitant, I LOVE journalctl, but in this instance, I see no need for that functionality AND I still have access to that if I want to. It’s not like adding a logfile for clamdscan to write to disables journalctl. Or does it??!?
If that is the case, then I actually choose the logfile in my home.
No problem, some people love to reach to their left ear-lobe using their right hand via their necks, others prefer to reach with their left hand directly.
It both works perfectly, choice is of the person self
Last tip:
Use systemctl show to view the parsed exec line to see if it actually shows what you intended before running the unit, of-course use daemon-reload in between edits…
The whole point of your dated log-siles is to keep them organized and in one place right?
The journal already does that and more…(it allows you fe. to filter on specific time ranges etc)
I don’t appreciate that comment about me, I choose to add one %, nest the command with bash and use a logfile in my home directory instead of journalctl and that is your comment. I say relax.
You realize that anyone here trying to help YOU is spending their own personal free time to assist you in a technical way and not to “please” your feelings right?
We have presented you with technical info and reasons, it’s up to you how to use that info or not at all. (I personally don’t appreciate blunt stubbornness in return.)
