Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm having difficulty understanding, even after reading the man pages about the systemd-tmpfiles cleanup portion of the service.
I basically want to delete all files that are in my /data/analyst directory when they are older than a certain amount of time (I haven't decided yet, but let's say 2 minutes).
Here is what I know:
I came across some good reading on the manpage for tmpfiles.d which said it would read conf files from /etc/tmpfiles.d/run/tmpfiles.d and /usr/lib/tmpfiles.d
So I figured I'd put a conf file in /etc/tmpfiles.d
Based on the reading and the format I added this:
# vim /etc/tmpfiles.d/new_tmpfile.conf
D /data/analyst - - - 2m
I waited for 2 minutes, nothing happened.
I used D because man page said that "D Create or empty a directory". I'm looking to empty a directory...
Anyway...what am I missing, and / or do I need to restart a service?
Last edited by scryptkiddy; 05-20-2016 at 03:43 AM.
That's an awesome and great cron solution for sure. But I was reading on the benefits of systemd timers, and the main benefits come from each job having its own systemd service.
Here is what I found in my reading up on them:
◾ Jobs can be easily started independently of their timers. This simplifies debugging.
◾ Each job can be configured to run in a specific environment (see the systemd.exec(5) man page).
◾ Jobs can be attached to cgroups.
◾ Jobs can be set up to depend on other systemd units.
◾ Jobs are logged in the systemd journal for easy debugging.
The problem is, I just don't know how to set it up. I can't find a clear procedure from start to finish with examples and explanations. I'd really like to dive into this since its something I've never used, and learn it so I can have another 'tool in the toolbox' for my UNIX skillset =)
Appreciate the feedback dab and jpollard, I'll look into it more. I do agree that cron would work. However, I'm trying to develop a new skill using systemd that Red Hat has implemented.
Right now it is designed to be the init system.
In theory, it can be a session manager and I think that is what they will turn it into...
When they successfully do that, it would be the program started instead of using the startup shell script, and will respawn various Gnome services if/when they die (control panels, window managers, the auto start scripts).
Personally, I think it a waste of time, memory and system resources (systemd right now takes almost 30MB just doing that) adding yet more instances is much bigger than a shortlived shell process that turns into the window manager.
Systemd right now can handle a laptop fairly well (a relatively simple startup), but I'm not yet convinced it can actually handle really large servers --- It still seems to have trouble mounting complex filesystems, getting things done properly with network startup, has forced daemon services to use non-standard coding for them to even work (each daemon has to tell systemd when it has really started... which wasn't necessary before, and cannot monitor standard daemons). It also still has trouble getting site specific startup procedures going (it gets tricky... and if you don't get it right it can randomly not work... or not shutdown properly).
If you want to stay on the bleeding edge of the systemd tech then grab fedora or arch for your laptop/home system. Its fun to see where it is going and keeping up with all the changes which will eventually end up in the enterprise distros.