systemctl --user list-timers
NEXT LEFT LAST PASSED UNIT >
Fri 2020-01-24 00:00:00 EET 16h left Thu 2020-01-23 07:58:01 EET 23s ago notes_daily.ti>
I have no idea why that happened. Anyone has any ideas?
My files, just in case.
daily.service
[Unit]
Description=Add Day Directory
[Service]
WorkingDirectory=/home/walter/
ExecStart=/home/walter/.scripts/daily.sh
daily.timer
[Unit]
Description=Add Day Directory
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
1.
Should I mark those two — .service and .timer — files as executables or not?
No, you shouldn't. It's not written in the wiki. You can check your .timer and .service files with
systemd-analyze verify ~/.config/systemd/user/daily.service
(as far as I got it, it checks both files).
Use the calendar command of systemd-analyze(1) to validate and normalize calendar time specifications for testing purposes. The tool also calculates when a specified calendar event would elapse next.
— the very end of man systemd.time(7)
To check whether your timer is present, you can use
systemctl --user list-timers
, which is (again) not in the wiki, it is not specified you need to make
--user
. Maybe when you have enough understanding it'll be obvious, I don't know, but it wasn't for me.
2. Also, I was confused whether the timer works or not, and I didn't know how to check it further than analyze it. I thought
systemctl --user start daily.timer
will trigger it at least once, but seems like it waits for the midnight, even though
Persistent=true
.
3.
mkdir $(date +"%m-%d-%a")
This command didn't work for me, I used it this way:
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'mkdir $(date +"%m-%d-%a")'
I tried it with double quote marks as well, no difference for me. I put this into a .sh file, which I run like this:
[Service]
ExecStart=/path/to/the/file.sh
Also, I don't understand whether I need to specify Type= at all, or not. I didn't understand the difference between simple, exec and oneshot. May try to give it a re-read one day later. At this point I'm trying to do my .service file without Type=
***
Those links may be useful for someone, who will read Arch Wiki, and will have more questions, finding this thread:
- man systemd.time(7)
- man systemd.service(5)
- Gentoo Wiki on Systemd Timers
- systemd.unit — Unit configuration
P.S. Didn't expect the forum formatting being so uncomfortable to use! I assume it has no in-line code tag.
]]>eric.meehan, thank you for your last post. It seems you are absorbing what's being thrown at you, and you shared your progress which can be a benefit to the community. These are signs that you can do well in this community.
However, I stand by my other assessments that you are over your head using arch. You will need to invest time and energy building up a knowledge of linux basics. If you work through the tutorial I linked to earlier, it should help bring you up to speed.
I appreciate your help and will definitely work through the tutorial you shared. As I said, this is just my preferred method of learning. I like to jump into the deep end and figure out how to swim. While this may not be a problem, perhaps the forums are not the place to exercise that method. Hopefully my future posts won't be so messy.
Best,
Eric
However, I stand by my other assessments that you are over your head using arch. You will need to invest time and energy building up a knowledge of linux basics. If you work through the tutorial I linked to earlier, it should help bring you up to speed.
]]>Alothough, my questions are slightly different, yet related to ‘.timer and .service’ topic name.
I have a script I want to run daily to create a folder, the bash command is
mkdir $(date +"%m-%d-%a")
which creates a dir named 01-16-Thu. I don’t understand how to make it, after reading systemd/Timers page. Should I create it myself, or does systemd handles it by itself? I think it’s not the dumb question, because before I tried to edit a systemd unit, not noticing it should be edit with
systemctl edit name.service
I have no idea whether I was correct on my manual change, as it was mentioned in another wiki entry, seems like it was. But I removed my manual changes and did them as it’s written on the wiki. I see no command for that. My command is simple, but as I understand Transient.timer units part, it’s for one-time events, and that can be run without a service file. But even if my command quite simple, I do need to have a file (two of them: .timer and .service), am I correct here?
I don’t understand whether I should run my timer as my user or as root? I need to create that directory in my home folder, but it’s going to be on a headless server, and I don’t understand how users are handled there, when I have no SSH-connection. Say, will my --user unit start when I do login, or it will also start after reboot, by itself? I have read systemd/User page and it’s still not clear to me.
Should I mark those two — .service and .timer — files as executables or not?
chmod u+x path/to/file
The problem with all that wiki wisdom as it’s not that clear before you actually try, and for some things it’s just quicker to confirm someone who already tried that, rather than experimenting on your own.
I know how to use crontab, and it’s easy. As it’s recommended to stick to the systemd.timers, I would like to learn how to use it, as it looks simpler from the first glance. But the manual is complicated.
]]>I've found the solution to my problem. Thanks again to all who tried to help. I'm going to be as explicit as possible with my problems and the solutions for anyone who views this in the future.
Thanks.
I still have a bit of a problem though. The python file is under the path /home/Eric/path/to/script.py, and should create text files with output in the same directory. However, the automation writes those text files to /home/Eric instead. In python, a script such as
file = open('data.txt', 'w')
should write to the same directory that the script is written in, since no absolute path is specified. Should I post this in a new thread, or is appropriate to continue here?
You could also tell your ExecStar=sh -c "..." command to first "cd /home/Eric/path/to/".
Alternatively, your python script could be made resilient to being run in systemd services and other cases where the working directory is not set, by telling the script the exact location of the file, you can do that in python by using os.path.join(os.path.dirname(__file__), 'data.txt') as the filename.
]]>What I trying to do:
I wanted a .timer file to execute a .service file of my own design every 10 minutes. On activation, the service file would enter a virtual environment for python, run the script I wrote, and then deactivate the virtual environment.
What I was doing wrong:
First and foremost, as pointed out by jasonwryan, I had my .timer and .service files in the wrong place. They were in:
/home/Eric/path/to/python/script/exchange.timer
/home/Eric/path/to/python/script/exchange.service
When they should have been in
/home/Eric/.config/systemd/user/exchange.timer
/home/Eric/.config/systemd/user/exchange.service
Moreover, my method of activating them was incorrect as well. I was using
sudo systemctl enable exchange.service
which Jason corrected to:
systemctl --user enable exchange.timer
No sudo, specifying --user, and activating .timer instead of .service. Thank you Jason for the input, I apologize for becoming short with you. You were right, I was haphazardly entering commands without knowing what they would do, and your advice was helpful to getting me on the right track. I appreciate your input.
Next was the .service file, in which I was trying to run three separate commands to enter the virtualenv, run the script, and then deactivate the virtualenv.
ExecStart=source /path/to/environment/bin/activate
ExecStart=python /path/to/script.py
ExecStart=deactivate
This was totally wrong, as pointed out by Trilby, who suggested I concatenate my commands to a single line and activate the environment using
ExecStart=/bin/sh -c "/path/to/activate; python /path/to/script.py"
This, however, was only part of the solution. Eschwartz had the simplest solution - there was no need to activate the virtualenv at all. I could simply specify running the script with the version of python in my environment folder:
ExecStart=/home/Eric/path/to/environment/python /home/Eric/path/to/script.py
The timer and service are both working now. Thank you to everyone who helped me, I appreciate your time.
I still have a bit of a problem though. The python file is under the path /home/Eric/path/to/script.py, and should create text files with output in the same directory. However, the automation writes those text files to /home/Eric instead. In python, a script such as
file = open('data.txt', 'w')
should write to the same directory that the script is written in, since no absolute path is specified. Should I post this in a new thread, or is appropriate to continue here?
]]>I wouldn't need to run the activate script if the package required to run the python script was installed system wide. I am using a library, alpha_vantage, for python that I have installed in a virtual environment. Without activating it, my script will not run. You're right, I wouldn't need it if I just installed it system wide, but that is not really the best practice for python.
I never said anything about installing it system wide, so I'm not sure what your response is supposed to mean.
Honestly, it looks like you didn't read my post at all, then tried dodging the question by making some strawman argument up to respond to. I hope that is not true, because if it were true, then we'd have nothing else to discuss.
Please reread my post and respond to the actual things which I said, if you want to discuss its content with me.
I have read the systemd page on the wiki, but searching for systemd.exec(3) or, as another user suggested, systemd.exec(5) does not return any pages. Could you share a link to the page you are referring to?
https://lmgtfy.com/?q=systemd.exec(3)
I'll admit to having typoed it, it is actually systemd.exec(5) - fortunately either one finds you the manpage in question via google. Did you try that?
You did not try finding it with the "man" program, or you would have found it when trying the section "5" version. Are you familiar with the use of Unix manpages?
Frankly, I know I don't know what I'm doing here. Its fine. I'm not running this on computers with files from the Pentagon. I am free to ruin the system and reinstall the os. There is nothing really important on it. It seems only natural to me that I would ask questions that don't make sense, its a great way to learn what you don't know.
No, it is not fine. https://wiki.archlinux.org/index.php/Fr … I_use_Arch?
If you are a beginner and want to use Arch, you must be willing to invest time into learning a new system, and accept that Arch is designed as a 'do-it-yourself' distribution; it is the user who assembles the system.
Before asking for help, do your own independent research by Googling, searching the forum and the superb documentation provided by the Arch Wiki.
It's fine to not know how things work. It's not fine to expect the Arch community to walk you through the simplest of things, such as how to read documentation. There are other excellent distributions and communities for that -- this is not one of them, this community specializes in enabling users to be their own troubleshooter, not in producing "Linux 101" walkthroughs.
All you will accomplish is frustrating other users, who are not impressed with how little you care about the community and attempt to trivialize it via bad jokes about the Pentagon.
]]>Frankly, I know I don't know what I'm doing here. Its fine ... its a great way to learn what you don't know. It is especially helpful when people tell me why my question does not make sense.
You're missing the point. It's not fine. You are in the wrong place. I tried to suggest this gently before.
I started writing up an analogy here when I remembered there is already a perfectly fitting and well written one by Xyne here.
You're holding up traffic in the crawling lane expecting everyone there to cater to your needs. You may have felt that Jason ("The Anarchist") was abrupt, but he is not here to serve just you, his contributions are for the maintenance and betterment of the whole community. On occasion, the best response is to tell someone that they are trying to swim in the wrong part of the pool.
Your assertitions that "it's fine" because you don't have anything critical on your system is like the novice swimmer ignoring complains about their presence by saying "I don't care if I'm putting myself at risk, if I get injured, that's on me." But it isn't. You are getting in the way of many other crawlers. Failing to recognize your impact on others is a very shortsighted and selfish perspective.
These forums are here to help archers. But we are not here to cater to every whim regardless of whether it is appropriately targetted in this community or not.
Really, for your own benefit get expereince with another distro before you use Arch. And if not for your benefit, for ours. Do not waste the goodwill and effort of this community when it could be much more useful to others.
]]>man 3 systemd.exec
eric.meehan wrote:You are correct on my intents for the environment. Rather than installing python libraries system wide, I am using a virtual environment that isolates those installations from the rest of my system. Entering the environment using the "source" command above allows me to access those libraries once I run a python script. Looking at the link you shared, it seems I need something like this:
[Service] Environment=SYSTEMD_LOG_LEVEL=debug
For my purposes, would I write it like this?
Environment=/home/Eric/path/to/virtualenvironment/bin/activate
Keeping in mind that "activate" is a script, not a directory.
More importantly, "activate" is not the literal value of an environment variable; how exactly do you propose parsing the filepath as a key=value pair for the Environment setting?
Did you read the systemd.exec(3) manpage to understand the meaning of the Environment setting, and also the EnvironmentFile setting, and why neither of them are at all what you want to do?
The thing is that a virtualenv "activate" script is really boring and just sets some fancy shell prompt that you don't need, plus adds /home/Eric/path/to/virtualenvironment/bin/ to your $PATH. You don't need that script at all, just use /home/Eric/path/to/virtualenvironment/bin/python directly.
Also, I appreciate your point, and will take a look at the tutorial you shared; however, I was simply not being clear with my confusion. I understand file permissions, I just didn't know what line in my .timer and .service file that particular line was referring to. Where is it marked executable?
Thanks again for your help!
Uhhhhhhhhh.
Configuration file /home/eric/.config/systemd/user/exchange.service is marked executable. Please remove executable permission bits.
The file .service is marked executable if you use the "ls -l" command to view the file. Do you suppose that file permissions are defined by a line of text within the file?
Your question is confusing and bizarre.
I wouldn't need to run the activate script if the package required to run the python script was installed system wide. I am using a library, alpha_vantage, for python that I have installed in a virtual environment. Without activating it, my script will not run. You're right, I wouldn't need it if I just installed it system wide, but that is not really the best practice for python.
I have read the systemd page on the wiki, but searching for systemd.exec(3) or, as another user suggested, systemd.exec(5) does not return any pages. Could you share a link to the page you are referring to?
Frankly, I know I don't know what I'm doing here. Its fine. I'm not running this on computers with files from the Pentagon. I am free to ruin the system and reinstall the os. There is nothing really important on it. It seems only natural to me that I would ask questions that don't make sense, its a great way to learn what you don't know. It is especially helpful when people tell me why my question does not make sense. This is more directed to Anarchist than you, as your comment was helpful, but simply saying I don't know what I'm doing is, as Anarchist's link itself states, "probably the most useless thing you could post".
]]>You are correct on my intents for the environment. Rather than installing python libraries system wide, I am using a virtual environment that isolates those installations from the rest of my system. Entering the environment using the "source" command above allows me to access those libraries once I run a python script. Looking at the link you shared, it seems I need something like this:
[Service] Environment=SYSTEMD_LOG_LEVEL=debug
For my purposes, would I write it like this?
Environment=/home/Eric/path/to/virtualenvironment/bin/activate
Keeping in mind that "activate" is a script, not a directory.
More importantly, "activate" is not the literal value of an environment variable; how exactly do you propose parsing the filepath as a key=value pair for the Environment setting?
Did you read the systemd.exec(3) manpage to understand the meaning of the Environment setting, and also the EnvironmentFile setting, and why neither of them are at all what you want to do?
The thing is that a virtualenv "activate" script is really boring and just sets some fancy shell prompt that you don't need, plus adds /home/Eric/path/to/virtualenvironment/bin/ to your $PATH. You don't need that script at all, just use /home/Eric/path/to/virtualenvironment/bin/python directly.
Also, I appreciate your point, and will take a look at the tutorial you shared; however, I was simply not being clear with my confusion. I understand file permissions, I just didn't know what line in my .timer and .service file that particular line was referring to. Where is it marked executable?
Thanks again for your help!
Uhhhhhhhhh.
Configuration file /home/eric/.config/systemd/user/exchange.service is marked executable. Please remove executable permission bits.
The file .service is marked executable if you use the "ls -l" command to view the file. Do you suppose that file permissions are defined by a line of text within the file?
Your question is confusing and bizarre.
]]>jasonwryan wrote:Did you read any of the wiki page I linked to?
systemctl --user enable foo.timer
Don't randomly insert sudo into commands in the deluded hope that it will somehow make things work. Privileges should only ever be elevated when you know what you are doing.
Seeing as I was trying to run a shell command in the .service file, I don't think this was the problem
Not reading the page was/is definitely a big part of the problem. Randomly using sudo is a symptom.
]]>eric.meehan wrote:I understand file permissions... Where is it marked executable?
Asking this question negates the statement. There is no line in a file that marks it as executable - that is not how permissions work.
Haha fair enough. I prefer to learn in this sort of environment though, so I appreciate your patience!
As for the virtualenv - I don't have much experience with them. If the "activate" file is a script, then it would not work quite like the environment variable examples in the documentation. You'd either 1) need to run the activate script and python script in the same shell invocation (to preserve the environment) or 2) dissect the activate script to get the actual environment variables that need to be set and put those in the service file. I'd prefer the latter, but - again - I don't use virtual envs, so the former would look something like this:
ExecStart=/bin/sh -c "/path/to/activate; python /path/to/script.py"
I will give that a try and report back on the results. Many thanks for the assistance!
]]>