Could you help to explain what this command is doing?
printf '#!/bin/sh\n\find /opt/traccar/logs -mtime +5 -type f -delete\n' > /etc/cron.daily/traccar-clear-logs && chmod +x /etc/cron.daily/traccar-clear-logs
Could you help to explain what this command is doing?
printf '#!/bin/sh\n\find /opt/traccar/logs -mtime +5 -type f -delete\n' > /etc/cron.daily/traccar-clear-logs && chmod +x /etc/cron.daily/traccar-clear-logs
This is a bit of a weird one.
Every morning I get an email telling me one of my certificates is expired.
################# SSL Certificate Warning ################
Certificate for hostname '*.floodtrack.com', in file (or by nickname):
/etc/pki/tls/certs/wildcard.floodtrack.com.crt
The certificate needs to be renewed; this can be done
using the 'genkey' program.
Browsers will not be able to correctly connect to this
web site using SSL until the certificate is renewed.
##########################################################
Generated by certwatch(1)
Where this is coming from is a frustrating mystery.
Running certwatch from the command line generates no output and a status code indicating the cert is good or cannot be parsed (status code 1).
sudo /usr/bin/certwatch /etc/pki/tls/certs/wildcard.floodtrack.com.crt;echo $?
1
Running the wrapper script at /etc/cron.daily/certwatch by hand does not generate an email and openssl report the cert has not expired
openssl x509 -noout -text -startdate -enddate -in /etc/pki/tls/certs/wildcard.floodtrack.com.crt
notBefore=Sep 20 00:00:00 2020 GMT
notAfter=Oct 21 23:59:59 2021 GMT
Apache is picking up and using the correct cert.
Everything about the email looks legitimate but it is obviously wrong. Any ideas on why it is happening and how to fix it?
I have an application that unpacks an archive into /tmp, restoring the extracted files' modification and access times. Sometimes these files and the enclosing archive are many years old. After the files are extracted (sometimes many minutes or hours later), the unpacking software will selectively use/modify some of the files. Once its done, the application will remove the extracted files/tree. This operation can happen any time of the day (e.g., at times when tmpwatch is run by cron).
Every so often, the application will freak out because it can't find a file that it knows it has recently unpacked. What I think is happening is that tmpwatch is descending into the unpacked tree after when atime/mtime is adjusted (by unzip or tar that is driven by the application) to the distant past but before the application can access the relevant file. Since tmpwatch is by default looking at atime, it thinks the file is decrepit and removes it.
Arguably, the unpacking could be done elsewhere or the application could use appropriate flags to not reset the timestamps to the past. However, neither of those approaches is viable for various reasons.
I think I might be able to modify the tmpwatch cron script to take all of this into consideration (and make the most conservative decision regarding removing the files) by specifying the --ctime argument as well as --mtime (and the previously implied --atime). I'm a bit confused by the term "maximum of these times" used in the tmpwatch man page, though -- my initial reading (until I looked at the C source and thought otherwise) was that it took the maximum of the differences (meaning that it was more liberal in removing things). Does it actually mean "latest of these times" (and thus tmpwatch will leave alone files that were just unpacked as their inode was only recently touched)?
On various systems that I administer, there are cron scripts that get run via the commonly-used /etc/cron.{hourly,daily,weekly}
layout. What I want to know is whether there's any common 'disable this script' functionality.
Obviously, simply deleting something out of a given directory will disable it, but I'm looking for a more permanent solution. Deleting /etc/cron.daily/slocate
will work to disable the nightly updatedb
on my home machine (where I never use slocate
), but next time I upgrade the slocate package, I'm pretty sure it'll reappear.
The two distributions I'm most interested in are Gentoo and OpenSUSE, but I'm hoping there's a widely-implemented mechanism. Both distros as I have them use vixie-cron (not sure it matters).
help me with this this problem. so far i have "find / -perm -4000 -o -perm -2000 | xargs ls -l > suild.list" argument that i want to write as a bash script.
I would like to write this as a bash script and be be able to run this nightly everyday. But im not familiar with the unix scripting language.
for crontab job, i need to write as * 24 * * *? I think? but i'm having trouble writing as a script.