New answers tagged

1

man 5 crontab suggests that a cronjob will find the owning user's username in the LOGNAME environment variable: Several environment variables are set up automatically by the cron(8) daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontab´s owner. HOME and SHELL can be overridden by settings ...


1

Get the script's owner On any system with as stat that is compatible with modern GNU stat, the user ID of the owner of the script is: stat -c %u "$0" The user name of the owner of the script is: stat -c %U "$0" In general on linux, stat -c %U file returns the owner of file. We substitute in $0 because that variable typically contains the name of ...


2

To find the filenames and script types of all scripts run from cron by non-root users (does not identify user): find /var/spool/cron/crontabs/ -type f ! -name 'root' \ -exec awk '!/^[[:blank:]]*(#|$)/ {print $6}' {} + | xargs -d'\n' file | grep -i script /home/cas/scripts/fetch.sh: Bourne-Again shell script, ASCII text executable ...


0

Depends on your distribution, you can place the script in a run level (that is executed after your user is logged). In contrast to cron, it will be executed interactively! You have to check what are your run level meaning (because you might changed it from the default). The default run levels for Debian & Ubuntu are: 0 System Halt 1 Single user 2 ...


0

It's because your shell uses environment variables that have different values then the environment variables that cron job have. Not all of the environment variables have different values but some of them. In not familiar enough with nmcli but you have to find out what environment variables it uses and then set them on your script before you call nmcli. That ...


1

You seem to look at your crontab with crontab -l. The corresponding command for editing crontabs is crontab -e. This command will edit crontabs that are generally in the directory /var/spool/cron/crontabs/. In this directory you will find files named after usernames owning the crontab.


1

The functions called (get_review_data, save_stats, check_for_new_reviews, etc.) should be listed within the php code and python code, /home/mycompany/public_html/index.php and /home/scraper/scraper.py Examining those files should show what's actually being executed.


0

In RHEL6 and RHEL7, see the init file, /etc/rc.d/rc.local: #!/bin/sh # # This script will be executed *after* all the other init scripts. # Your can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff. touch /var/lock/subsys/local Even though RHEL7 replaced System V with systemd, the same file can be used. ...


0

/etc/profile.d is a vendor-specific means of customizing the environment of a shell session (setting PATH and so forth), and would not typically be related to the startup of a daemon; some would even argue that daemon startup should in no way involve /etc/profile.d, so that user shell customizations cannot cause a daemon to fail to load, or to load with ...


0

You can put: MAILTO="" at the beginning of your crontab file and that will prevent it from trying to send email.


1

The exact sequence in which jobs are executed will depend on the implementation of your systems' crond. What is your OS? If you have cronjob in a crontab: Job 1 Job 2 Job 3 In Debian Job1 will start, without waiting to finish Job 2, etc. In Debian and Ubuntu derivatives it is top-bottom In FreeBSD it is bottom-top If your cronjobs are in ...


2

crontab entries are processed independently, so yes, the jobs are run asynchronously, in parallel. You don't need to background them. If you ever need to synchronise jobs, check out the techniques mentioned in Can a crontab job run concurrently with itself?.


-1

No need to install daemontools, runit, supervise, etc. As useful as these tools are, they cover use-cases you generally are not in need of for only cron. What you simply need can be handled at ease with init. Add to /etc/inittab: cron:2345:respawn:/usr/sbin/crond -n Make sure crond supports the -n option first. This tells it not to fork and to remain in ...


0

You can always check out the monit project. You can restart services and keep them up with it. If there is no way for you to fix your cron as comments suggested.


0

No, currently this is not possible. A feature request has been filed: https://github.com/systemd/systemd/issues/3107


1

Couldn't I run something like daemontools to monitor and restart the process? Yes, indeed; and on some machines I do exactly that. The "something like daemontools" is actually the service manager from the nosh package but other members of the daemontools family are more than capable of supervising GNU cron. (Vixie cron is another matter, but you did ...


-1

Since one cannot monitor crond via crond i'd make it this way: echo "while true; do if ! (ps aux |grep crond |grep -v grep); then /etc/init.d/crond start; fi && sleep 5; done &" >> /etc/rc.local


0

I'm not sure if it because initctl dose not support the rotate option, and when it was removed, but you are not the only one effected by this, and there are open bug report for this on launchpad. Bug #1450770 “logrotate action “rotate” failed” Bug #1476296 “Nginx 1.8 (stable PPA) service commands don't work...” As mention by other answers ...


1

It's written but not where you're looking for. The best way is using absolute paths.


3

First rule of crond club: you don't assume the working directory. My guess is that you'll find a crond.log in /root. If you want it in /vagrant, explicitly redirect the output to /vagrant/crond.log. (FWIW, the second rule of crondclub is: don't assume there's anything in your PATH, use explicit paths to binaries, but since echo is also a bash builtin, ...


2

root has full access on your system, but doesn't necessarily have all the keys to other systems that your normal user account has. So the trouble is: rsync -avz /home/user/backup user@myserver:/home/user/ ^^^^ If you cause root to execute this command as you, your keys will be used and the command will be successful: sudo -u ...


4

Would not be better if you compress your files and keep less of older logs instead of spending time creating a script? THIS is why logrotate exists. Take a look at your logrotate.conf. It should start with something like this: # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) ...


2

Don't edit a crontab file directly. Use the crontab command, that's what it's for. Don't use sudo multiple times in a script. Run the entire script with sudo. Quote your variables and strings properly. Single-quotes around literal strings, Double-quotes for variable etc interpolation. You should be grepping for fixed strings rather than regular ...


2

For cron edit purpose l0b0 answer is the best way, to fix your script you have to: escape dots and asterisk in your search key (updateKey) use alternative separator in sed (I choose %) double quotes around sed expression (you want your bash variables resolved) #!/bin/bash CCgenerator="0 06,18 * * * /home/server/scripts/CCgenerator.sh" updateKey="0 05 ...


2

Rather than update the crontab directly you'll want to use a standard mechanism to add a cron job: line="* * * * * /path/to/command" (crontab -u userhere -l; echo "$line" ) | crontab -u userhere -


2

Does /temp really exist (didn't you mean /tmp)? If it doesn't then your script tries to cd to /temp, fails, and then all the commands run in the starting directory. The last two commands are particularly dangerous because you cd to /, then cd to /temp (which may not exist) and then rm everything (which could well be the root filesystem). You should ...


1

In my opinion you should never ever disable the root user entirely. If you do not want to be able to login as root using ssh you should set the directive PermitRootLogin no in /etc/ssh/sshd_config. For other applications there are mostly equivalent settings which can be made.


0

Expanding on @Cyrus answer this is what I did: I made a script which checked a UTC offset: #!/bin/bash export TZ=":US/Eastern" if [ "$(date +%z)" == "$1" ]; then shift exec $@ fi Then I add two crontab entries each for the offset I want: 0 8 * * * run-only-with-tz.sh -0400 place_your_command_here 0 9 * * * run-only-with-tz.sh -0500 ...


2

Here are some points about those two (hope would answer your questions): 1. checking what your cron job really does can be kind of a mess, but all systemd timer events are carefully logged in systemd journal like the other systemd units based on the event that makes things much easier. 2. systemd timers are systemd services with all their ...


2

The entries are added to the log each time a cron job runs. To reduce the time between entries, you would have to look at your cron jobs and change their timings. This, though, may break something that relies on those jobs running at specific intervals. If they really do annoy you, then simply follow the instructions on the Debian bug report and stop cron ...


3

Solution to the problem is to modify the entries in cron with the absolute path names. Added cron command logging capability as the machine doesn't have an MTA to send failure notifications, as follows: 0 0 * * * /usr/local/bin/bitcoind -datadir=/home/pi/bitcoinData -daemon >> ~/bitcoinData/bitcoin-cron.log 2>&1 0 6 * * * ...


2

Applications run from cron have no "console". Both stdout and stderr are captured and emailed to the local user account when the job completes. In your case the script is run as root, so the result will in in root's email. As for writing to the file, the ~ represents the root user's home directory, i.e. /root, so that is where you need to look for the ...


3

There are several places where cron-jobs are stored. The main place, is /etc/crontab (and on some systems, this is the only one). This file is edited only by root, and often allows to specify which user the job should run as. On some systems, there is also a directory - /etc/cron.d - which complement /etc/crontab. The files here contains line(s) like ...


0

The only difference between using COPY and RUN are the permissions on the /etc/crontab file: with COPY this is 664 and with RUN 644. I cannot find anything on permissions that /etc/crontab needs to have but if you add RUN chmod 644 /etc/crontab after the COPY line in your Dockerfile the cronjobs run (at least for me). So I think the permissions have to ...


0

Why you didn't try to edit /etc/rsyslog.conf ?! As you know you can force rsyslog to log service that hasn't specific logger. So I suggest read man rsyslog.conf to know how make service making log and edit the service to send logs here ( edit somewhere like /etc/init.d/rsyslog to configure log section ).



Top 50 recent answers are included