Tag Info

New answers tagged

0

After wasting some time I got it working. I just had to escape the character like this: $pass = '\)d@340kgfj';


1

Your cron seems not to know or use the &> shortings from bash. When you write the redirection like this /home/archiver/archiver.sh >/home/archiver/output 2>&1 it should work.I would prefer >>/home/archiver/output 2>&1 to always append to the logfile, too.


0

You can always use Cron job simulators to validate you Job run schedule. Link for one of the cron job simulator - http://www.dataphyx.com/cronsandbox/


2

You can do it with this: { crontab -l; echo "30 23 * * * /path_to/script/"; } | crontab -


0

Problem resolved: Change permissions on /usr/bin/crontab [root@dub-ImrORA2 log]# ls -al /usr/bin/crontab -rwxr-xr-x 1 root root 315640 Dec 20 2011 /usr/bin/crontab [root@dub-ImrORA2 log]# chmod 4775 /usr/bin/crontab [root@dub-ImrORA2 log]# ls -al /usr/bin/crontab -rwsrwxr-x 1 root root 315640 Dec 20 2011 /usr/bin/crontab Change owner on ...


1

Cron doesn't start with common environment variables that your user has, including $PATH. You have the full path in your cron, which is good, but you need to add it to your script as well. which lsof and which seoserver will give you the full path. Modify your script to use that instead of lsof and seoserver.


0

This works if you don't mind copying the most recent file to another directory while the rest are removed. Assuming you're current working directory is the one with the logs: cp $(ls -Art | tail -n 1) /tmp \ && rm -ri /path/to/logs \ && cp /tmp/$(ls -Art /tmp | tail -n 1) ./ \ && rm -i /tmp/$(ls -Art /tmp | tail -n 1) Broken down: ...


0

If you cannot know that only one file per day is generated (your failing command would work in that case), you have to pipe the output of find in which you have a combination of the date-time-stamp of the file and the filename into sort and then exclude the final line with sed before splitting of the date-time-stamp (again with sed) and feeding the resulting ...


1

Almost all problems with scripts properly running from the commandline, but not from cron come from the setting of the PATH variable. According to man 5 crontab for Vixie cron: On the Debian GNU/Linux system, cron supports the pam_env module, and loads the environment specified by /etc/environment and /etc/secu‐ rity/pam_env.conf. It ...


0

Two options: Option 1 - Have you chmod +x test.sh? That way you can execute with ./test.sh rather than sh test.sh. Option 2 - If you don't want to chmod the file, change your crontab entry to * * * * * /usr/bin/sh /home/username/test.sh Additionally, if you choose the latter, you should verify the sh binary location with which sh


1

Yes, those files are considered configuration files. Generally, (at least) everything in /etc is considered a configuration file in Debian. That's why it takes a purge to remove them. The reason they are configured configuration files is that anything that the system administrator is reasonably expected to customize or edit should be considered a ...


4

Using just 56 on the first field you are telling cron you want to run the script at minute 56; while setting "*/56" on the first field you are telling crontab to run the script every 56 minutes. If You want the script to run at 12:56PM, 01:56PM, 02:56PM ...; then you use 56 56 * * * * /usr/bin/python3 /home/asd/asd.py


0

There are a number of problems remaining: You created the fine on a Windows machine and copied it to the server. Unless you have a "text transfer" mode this leaves CR/LF endings for each line. As suggested by others run dos2unix on the file to fix this. Remove the leading spaces from the #! line, as already suggested by others. Do not write to ...


0

Update (from our chat): Your question shows spaces at the beginning of #!/bin/bash please make sure that none exist. Also if you did any windows to linux copying try running the following command, to remove any ^M characters and try running the script again: sed -i s/{ctrl+v}{ctrl+m}// /usr/local/optimize.sh Or if you have dos2unix run: dos2unix ...


0

Your cron line format is wrong. Here is an example: 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/ i.e. don't name the user, you only put the user name in if you are adding lines to /etc/crontab, but if you are using crontab -e then you are adding to the current user's crontab file.


0

Answering this question because it'd bad form to just edit your question to put the answer inline (really, just answer your own question, it's okay if done in good faith). I had a similar problem - jobs started via cron appearing to work the first few times, but then failing. The symptoms all traced back to an inability to access the user's home directory ...


1

What you've written in your crontab entry doesn't match your stated need. The manpage (man 5 crontab) is reasonably clear on this: Step values can be used in conjunction with ranges. Following a range with "/" specifies skips of the number's value through the range. For example, "0-23/2" can be used in the hours field to specify command execution every ...


3

Have you looked at this? I think what you are looking for is: 5-59/15 * * * * /root/job.sh >> /root/job.log


2

Few things: -add some kind of the timestamp to the job. -don't redirect anything to the /dev/null . -set a $MAILTO notification to send output to the required team We are using Nagios for this and also cronwatch


0

The tar exit codes are documented in the "info" manual - use info tar to read all about tar. (You can read about "info" with info info). It seems there are 3 (major) exit codes. From the info tar documentation: Possible exit codes of GNU 'tar' are summarized in the following table: 0 'Successful termination'. 1 'Some files differ'. If tar ...


1

The solution that worked for me is I changed all of the paths within my two programs from relative paths ie: (./name_of_file.txt) to full paths (ie: /home/ed/directory/some_more_directory/name_of_file.txt) Was it just this, or a combination of the other things I did, I don't know - but changing the paths from relative to full path did it.


4

cron by itself doesn't support this. The eariest way to accomplish what you want is probably to ask cron to execute a dispatcher script every day (at the same time) and have the dispatcher script decide which other script to run based on what day it is. For example: #!/bin/sh case $(expr $(date +%s) / 86400 % 5) in 0) exec /script/for/day/1 ...


0

Setting $PATH, as others have suggested, is always a good practice in scripts that may be called from outside of your interactive environment. When you are calling the scripts from your shell, you probably cd to the containing directory first. You'll also need to do that here. cron may run your script with a working directory of / or /var, for example, so ...


0

I think you need to set the path variable in the script For example PATH='/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin'


0

Found the problem. it was not finding sendmail when executed through cron, I had to specify the full path of /usr/sbin/sendmail and it worked!


0

You must separate the brackets from the data with spaces, like this: for I in 0 1 2 3 4 5; do check=$(uptime | tr -d ',.' | awk '{print $10}') if [ "$check" -gt 5 ]; then /usr/bin/systemctl restart httpd.service fi sleep 10 done In UNIX, [ is really a shell command. When the shell replaces the $check variable by its value, it will ...


1

Your cron job is set to be executed at 20 hour 5 minutes (24 hour format). And the log you provide is from 9 a clock. So you should wait till 20h to see it in the log. And do not enter leading zeroes, this is not good practice, make your record like: 5 20 * * * root /data/CENTRAL_BACKUP/xxx.sh


1

The first error is clear; the line you've commented out gives the permission that audit says is missing. The second part is more interesting, but what I suspect is the problem is the target context of the socket you're modifying (owned by unconfined_u). Because you've moved to static device nodes, your interfaces are no longer created by the openvpn process ...


2

No need to use a for-loop here, you can just use find: sudo find /var/log/ -type f -regex '.*\.[0-9]+\.gz$' -delete However, as suggested, check the manual page of logrotate for ways to reduce the number of files.


2

Often times when applications are being killed, it is always a good idea to take a quick look at your /var/log/messages file to see if the kernel is killing the process. The most common trigger (in my experience) has always been due to out-of-memory (OOM) errors, since my company primarily uses java applications, it is quite common for the devs to publish a ...


0

I don't SELinux, so can't assist with that. However, if your issue is keeping OpenVPN running, you may consider code like this: while sleep 5; do /command/to/start/OpenVPN done This assumes OpenVPN is running in the foreground. You may need to change your OpenVPN command line options to get it to stick in the foreground. This script sleeps five ...


0

I used the above information and wanted to provide one more minor update that actually truncates one of the really large tables that was slowing up our backups. Hopefully this helps someone else. Using the above information I created a basic shell script named mysqlbackup.sh with the following content: #!/bin/sh find /data/var/backups/mysql/dumps -type f ...


1

Replace this: 50 5 * * * /home/user/bin/sync-folder With this: 50 5 * * * /home/user/bin/sync-folder > /dev/null 2>&1 Add email inside script: #!/bin/bash sudo rsync -rav --delete --log-file=/tmp/rsync-output /origin /destination grep folder /tmp/rsync-output if [ $? == 0 ]; then mailx -s "Rsync Complete at `date +"%F %T"`" ...


1

find path-to-base-dir -maxdepth 1 \ -type d ! -name bunch-of-exceptions \ -mtime +7 -exec rm -rf {} \; -print You did not include path-to-base-dir in the bunch-of-exceptions. (You included . but that would only match if path-to-base-dir was exactly .) The only condition that the directory path-to-base-dir might fail if -mtime +7. If the ...


0

It is a bit dirty, but I would put a file in /tmp or some other place which gets removed when the server is back up again. Maybe something like this: #!/bin/sh output=$(wget http://lon2315:8081 2>&1) pattern="connected" websitedownfile="/tmp/websitedown" if [[ ! "$output" =~ "$pattern" ]]; then if [[ -e $websitedownfile ]]; then echo ...


4

I don't think you can use environment variables, as they won't persist between script "runs". Alternatively, you could write to a temporary file in /tmp or somewhere in your home directory, then check it each time? For example, something like #!/bin/sh output=$(wget http://lon2315:8081 2>&1) pattern="connected" tempfile='/tmp/my_website_is_down' ...


0

Put those [dir1] strings in quotes, otherwise the shell will try to expand them because of the brackets, which may or may not succeed according to the contents of your current working directory.


1

I recommend using at, not cron, because that way you won't have to remember to remove the crontab entry when the 24 hours are up. Just schedule 8 identical at jobs to run at the desired times (each 4 hours apart). In each job, you can, for example, use curl or wget, but of which can easily support writing the downloaded contents wherever you want it.


0

First of all, for debugging purposes, redirect the stderr to some file as well. This way you'll know what goes wrong. 15 * * * * /bin/ksh /wls_domains/resMGT/logs/bea/wlr3queuetransaction.sh 2>LOG_FILE > /wls_domains/resMGT/logs/bea/data/script.log Next if it isn't a file location issue, take a look at this question, as it is very similar: how to set ...


1

Your script does cat wlr3queue.txt etc.... where are those files to be found? When you're trying by hand you're running ./wlr3queuetransaction.sh but from cron you're calling with the complete pathname. Cron will run your command from the crontab's owner's home directory; presumably the files you're accessing in your script aren't in that home directory. ...


2

Items in crontab execute with a limited environment. At the top of your script you can specify your PATH, for example, PATH=$PATH:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin or alternatively you can call each executable with its absolute path.


2

It slightly simplifies system administration, because users can be locked out by using /etc/nologin and kill, without having to worry about processes coming back through cron or at. It shouldn't be a big problem if you can run your own cron daemon.


1

If you need default system wide PATHs and other ENV variables (which defined in /etc/profile.d), just put the following: * * * * * . /etc/profile; your cmd



Top 50 recent answers are included