New answers tagged cron
Ensure that your crond is running. Also make sure (and test this) that it will start on boot properly.
The message comes from PAM which is consulted every time a shell is spawned. See contents of /etc/pam.d, especially files /etc/pam.d/common-session and /etc/pam.d/cron. This message means that there is indeed a cronjob somewhere which is run by the root user. That does not mean the job is doing anything (it might, for example, just check if a certain ...
Short wording solution: comment HOME=/ directive in your /etc/crontab file Now explanation: I found this topic because my mysql backup script , flushing bin-logs , worked just fine interactively, but failed when cron. But it occurred, that my setup was slightly different from Rudra’s, so the root cause and solution either, but still let me post it here ...
My first guess is that the mysqldump command isn't in the path when the script is run by cron. Try: which mysqldump Take the output of that and substitute the whole path for the command name. Eg: /usr/bin/mysqldump instead of mysqldump Or add something to a local PATH variable. Eg: PATH=$PATH:/usr/bin This will also solve problems if tar, chown, or ...
problem in the mlocate. messages sends directly from server-ip server. go to /var/spool/cron/ and do grep -ir MAILTO , the same check for MAILTO entries in the /etc/crontab file. if you do not want to receive messages from crond simply remove MAILTO string (probably by an earlier updatedb) <- if you started receiving messages today, then just give ...
It really helps if you specify what OS you're on. I'm guess this is some Linux distro... It's running /etc/cron.daily/mlocate and that script is erroring, you should probably fix that. I don't see a question anywhere in there.
Assuming you're using ident authentication (or a .pgpass) for the database I'd probably do something like the following : pg_dump -Udbuser -h127.0.0.1 mydatabase |gzip -c > mydatabase.backup.gz; scp -P 122 mydatabase.backup.gz firstname.lastname@example.org:; rm -f mydatabase.backup.gz Editing to add another option... If it's really important to not have ...
I'm assuming you know the name of the script (use pkill), or can find out its processid (ps aux, then kill -9). Then start it again using the same command as in crontab. If you want to detach the process from the session, you can use nhup, or dtach or something similar. Its pretty trivial. A better way to do this would be to write a init (or upstart or ...
I found the problem. It was not in the log folder, but in the cronjob task. Fixed! Fixed it by adding the log folder and giving it 770 premissions so root:root can access it in proxmox. It does not write anything to it, but proxmox VM needs it, even if the VM is not running. Proxmox deleted the log folder in rotation.
Top 50 recent answers are included