Tag Info

New answers tagged

0

Kill it! #!/bin/bash killall epiphany And btw: on my system (Debian Jessie) the process name is just epiphany. You can see the process list e.g. with ps -A.


5

Jodka Lemon's answer is correct: cron executes its job, and sends a result mail to "root@orion" (via "mail" or similar) the MTA cannot resolve host orion, since the hostname is not listed in /etc/hosts and not resolvable via dns. so the mailer writes the dead letter information You will find the destination address of crons mail output in the crontab ...


6

Change the following line in /etc/hosts 127.0.0.1 localhost to 127.0.0.1 localhost orion Your MTA was unable to resolve the domain name of your machine.


0

Problem is solved. It was not due to a bug in Cron but it was because the LDAP client of our compute cluster was restarted on the hour. So therefore all CRONjobs scheduled at this time weren't executed, because the cluster couldn't recognize user IDs.


0

I had to figure this out as well but at the very least executing casperjs requires you to have variables available that are loaded when you load a shell as a log-in shell. In my case I didn't feel like hard-coding the path to casperJS in my script because it was already set in the $PATH on my mashine. This then lead to the discovery that just spawning a ...


4

It's because cron forcibly sets PATH to /usr/bin:/bin. You need to invoke iptables as /sbin/iptables or add PATH=/usr/sbin:/sbin:/usr/bin:/bin in your script or crontab. See crontab(5) for details.


0

This looks like it is covered well here: crontab's @reboot only works for root? basically the answer depends heavily on what you use for Cron and your Linux distribution.


2

I don't think it's a bad idea to harden your system by protecting accounts as good as possible as you can. In many situations it will introduce extra hurdles during authentication, but if you're willing to cope with that it's all fine. An important thing to take into account, though, is the risk of actually introducing more flaws by increasing the complexity ...


0

What do you mean by "reset the time lapse on cron"? Times in crontab are basically specified in the absolute time except for @reboot. @reboot jobs are not executed on restarting because it checks existence of /var/run/crond.reboot. So I think there would be nothing you have to care about for times to run cron jobs. */5 * * * * is equivalent to 0-59/5 * * ...


5

I'm not sure why you would want to do that. If you're concerned about security, if someone discovers your password on 1 July, they'll know it on 31 July or 15 September... To answer your question, if you want to ensure that the password update is done either at a scheduled time or when the system restarts, you want to install anacron. It can do periodic ...


0

Why do you want remove your system MTA? This only give you problems, many apps require MTA for right working. I recomend you don't do that. In addition, the charge on the system is trivial if it don't have activity. Regards,


0

SOLUTION - I got this script to work. thank you for all the support you gave, If i have enough time to be working on this i'll keep trying the other options and make them work as well. #!/usr/bin/python import os from ftplib import FTP local_path='/path_to_local_files/' os.chdir(local_path) ftp = FTP(host='server_name_or_IP',user='username', ...


0

You do keep the "old"er files on the source ftp, don't you? If this is the case, the perfect tool to update/sync your local directories would be lftp, which features a mirror command: lftp -e 'mirror remoteDir localDir;exit' -u 'remoteUser:remotePassword' remoteHost This would connect to remoteHost as remoteUser using remotePassword, then execute (-e) the ...


1

Have you looked at rsync? From how I interpret your question, this should accomplish exactly what you want. Here is a description how to setup an rsync daemon to connect without ssh.


1

The shebang is working and cron has nothing to do with that. When a file is executed, if that file's content begins with #!, the kernel executes the file specified on the #! line and passes it the original file as an argument. Your problem is that you seem to believe that SHELL in a shell script reflects the shell that is executing the script. This is not ...


-1

Change the shebang to #!/bin/env bash Or execute crontab -e to have the script run with your own environment variables, as cron's own are different. As a side note, according to this post on askubuntu, you need to give your cron a PATH at the top of the script: PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # ...


1

Bash Reference Manual says: SHELL - The full pathname to the shell is kept in this environment variable. If it is not set when the shell starts, Bash assigns to it the full pathname of the current user’s login shell. man 5 crontab says: Several environment variables are set up automatically by the cron(8) daemon. SHELL is set to /bin/sh, and ...


1

Could the query just be returning nothing? You could add some extra checks: sqlplus -s << $query > ${query_log} # check if the sqlplus command actually worked if [[ $? -ne 0 ]] ; then echo "error: Query failed!" >&2 # or mailx -s ... (cron will email stdout/err anyway) exit 1 fi # check the query is not empty if [[ -s ${query_log} ...


2

Those environment variables such as ${ORACLE_HOME} are perhaps in your bash profile. This does not get read via cron automatically. Insert the line below after the #!/bin/bash. source /home/user/.bash_profile


1

Here is a solution which will both unlockpt() a new pty descriptor and write its ptsname() to stdout for you. <<\C cc -xc - -o pts #include <stdio.h> int main(int argc, char *argv[]) { if(unlockpt(0)) return 2; char *ptsname(int fd); printf("%s\n",ptsname(0)); return argc - 1; } C Which just compiles a tiny ...


1

0 9 1-7 * * runs the job once per day (at 9:00), but only on the first 7 days of the month. That's one way to run a job on the first Monday of the month: run it on the first 7 days, but don't do anything unless that day is a Monday. 0 9 1-7 * * if [ "$(date +%u)" = 1 ]; then do_stuff; fi 0 9 * 1 * runs the job every Monday. That's another way to run a ...


0

Here is a less complex script than what Graeme provided. His script didn't work for me, $who_line was always empty. My script doesn't waste so much time with finding a process. Instead, it just tries all and pick the last useful value found. I'm running xubuntu 14.04 and have some lxc containers running which probably confuse this kind of scripts. env="$( ...


0

#* * * * * command to be executed #- - - - - #| | | | | #| | | | ----- Day of week (0 - 7) (Sunday=0 or 7) #| | | ------- Month (1 - 12) #| | --------- Day of month (1 - 31) #| ----------- Hour (0 - 23) #------------- Minute (0 - 59) Yours is correct. After five astreisks, there must be a shell command. You can confirm the cron tab is running or not, by ...


0

So I'm not sure why ntpdate seems to be running if you have NTP installed. You don't mention what OS/distribution this is on, so I'll have to keep this general, but: Remove any crontab calls to ntpdate and remove the call to ntpd -q. Remove ntpd from your system package manager and reinstall it. View /etc/ntp.conf and make sure the upstream timeservers are ...


0

The docs I was reading were incorrect, so the bit about file syncing is completely wrong. The '-' removes logging from a file, so here's what I added to my system to log cron entries into /var/log/cron.log + disable /var/log/syslog duplicate logging. ... .;cron,auth,authpriv.none -/var/log/syslog cron.* /var/log/cron.log ... ...


0

There is no requirement to reboot (shutdown -r now). Try this. From one window run: tail -f /var/log/syslog From another, run: service rsyslog restart 1) make sure rsyslog stops + restarts with no errors. 2) the tail of syslog will likely tell you what's required to fix. Keep in mind, your logging may be working. The '-' in front of log file ...


2

xrandr needs the $DISPLAY variable set to tell it which X session it's manipulating, and that isn't being set in the cron environment. xrandr could be working on your default local X session, or a second one that you started by running startx from a TTY, or a session to a remote display being forwarded over SSH, or a nested X session running inside another ...


4

Don't use password authentication. Use ssh keypairs. Karthik@A $: ssh-keygen #keep the passphrase empty Karthik@A $: ssh-copy-id B #enter your B password #^ this will copy your public key to Karthik@B:.ssh/authorized_keys From then on, you should be able to ssh from A to B (and by extension, scp from A to B) without a password.


0

Generate an ssh-key on server A using ssh-keygen. This will generate a private and public key pair in $HOME/.ssh. Add the public key to the $HOME/.ssh/authorized_keys file on server B. You can use the man command to get more information. The command man authorized_keys will present the manual page that discusses authorized keys. Try the following sites ...


7

Restrict the commands that can be invoked by the key If an SSH key is going to be used by any kind of automated or unattended task, you should restrict what commands it is able to execute on a remote machine, no matter what decision you make about how and where to store the key. Use something like this in ~/.ssh/authhrized_keys: ...


0

I know the answer is different, but is there a reason you don't use the built-in commands? such as this is crontab @reboot /usr/sbin/ipset restore -f /ip/ipall.txt and ipset save -f /ip/ipall.txt


4

This is handled by anacron, which runs the default cron.daily etc. jobs on Fedora. If this is a root job, you can either add it to the /etc/cron.daily or to /etc/anacrontab.


0

I couldn't solve this problem but this is the workaround which worked for me: I defined a new script run.sh which does something as the following: #!/bin/bash while true do run_process_a.sh sleep 60 done Then I defined a couple of other scripts service.sh: A daemon script start.sh: A wrapper to start an instance of run.sh and store its pid ...


1

You can also put your commands into a shell file and then execute the shell file with cron. jobs.sh echo hello >> ~/cron-logs/hourly/test`date "+%d"`.log cron 0 * * * * sh jobs.sh


1

I'm assuming by parent folder you just mean the folder with filename.txt. You can get find to print this folder name with -printf '%h\n' instead of the -exec. You can pipe this into a shell loop or xargs for example: find /path/ -name "filename.txt" -type f -mtime -2 -printf '%h\n' | xargs -i rsync ... {} /destination \; I think you need to add -R to ...


0

Your asking for more information led me to finding out that the program had to be started after LXDE was ready for a desktop session. And as such I googled and found out that /etc/xdg/lxsession/LXDE/autostart contains a list of applications that will be starting after the desktop session is started. I added @mono myapp.exe And rebooted and it worked! ...


1

use nohup scriptForB.sh inside scriptForA.sh... in that way, the child process will not be terminated when the parent process exits.. On termination, parent process will send SIGTERM signal to all child process. If you use nohup, the child process will ignore the SIGTERM signals.


0

Use full paths to ensure the functionality. In the mboxutil situation, you must know where's the command located. Execute: $ type -a mboxutil mboxutil is hashed /opt/sun/comms/messaging64/bin/mboxutil Update your script: /opt/sun/comms/messaging64/bin/mboxutil -l > /path/to/n.txt sed 's/^.*user//' /path/to/n.txt > /path/to/n1.txt cat ...


1

You can simulate the cron user environment as explained in "Running a cron job manually and immediately". This will allow you to test the job works when it would be run as the cron user.



Top 50 recent answers are included