Run CURL in Cron Can't get result

My TrueNAS Core runs on a local network and I need to obtain the external IP address and write it to a file for other devices to read. I found a website, 4.ipw.cn, which returns the device’s external IPv4 address when accessed. The output is as follows:

root@home-nas[~]# curl 4.ipw.cn
111.22.33.44
root@home-nas[~]#

I created the following command in cron:


/usr/local/bin/wget 4.ipw.cn -q -O /mnt/pool1/pub/homeip.txt

or sh file

#!/bin/sh
homeipadd=`/usr/local/bin/curl -s 4.ipw.cn`
/bin/echo "$homeipadd" > /mnt/pool1/pub/homeip.txt

The commands runs success when executed in the shell, but once I add it to cron for scheduled execution, it fails to produce any output.

Using the curl command to store the result directly, or using a script to echo the returned IP address into a file, also fails to execute successfully when scheduled in cron. Both wget and curl commands have been tested in the shell. Concerned about cron’s PATH, I used absolute paths for all commands, such as /usr/local/bin/wget or /usr/local/bin/curl.

Even switching user identities (such as root, deamon, nobody) in cron does not result in successful output or saving to the file.

Could anyone help me figure out what the issue might be? Many thanks!

Put this line at the top of your script (after the #!/bin/sh):

exec >/tmp/debug.log 2>&1

If that does not get created either, there should be some error message in the cron log. If cron can and does execute the script all following errors should end up in that debug.log

2 Likes

* * * * * /bin/curl -s 4.ipw.cn > /root/ip.txt
Tested this and it works fine (SCALE). Can’t see any reason it wouldn’t work on CORE.

If you’re looking for something more consistent rather than querying a website you don’t know will stay available, I’d recommend using Cloudflare’s lookup. It’s what I have used for years and have yet to run into an issue with it. It’s also considerably faster than querying a webpage.
dig +short txt ch whoami.cloudflare @1.1.1.1

1 Like

i’ll try,thx

My hunch is the shell you’re using.

Can you try again with
#!/usr/local/bin/bash

I don’t see any bashisms in the code. Should run fine with POSIX.

1 Like

It WORKS!!!
THX!!!
I believe I used curl -s so I don’t have to worry about output data. Praise “2>&1”, praise pmh!!

I even used zsh, bash, and csh, it doesn’t seem to be a shell issue. The problem is exactly what pmh mentioned:
exec >/tmp/debug.log 2>&1

Ah … so there wasn’t an error in the “debug.log” at all? The command just hung because it did not have a controlling tty, probably?

You should be able to fix that the intended way by marking both the “suppress standard out” and “suppress standard error” options in the cron job UI.

Nothing in debug.log,.sh in cron works fine.
I tried selecting/deselecting those two options, but neither had any effect. It seems that exec started a thread that is undisturbed. Thanks again.

SIDEBAR: Argument for using “#!/bin/sh” (in addition to the above axiom).
The rc.d system uses sh functions and so should we. I’m no expert or professional by any means but in my experience, keeping things consistent makes life so much easier -i.e. adding to [your] “rockstar reputation” by expanding into writing rc.d scripts. Using sh functions in scripts also promotes code reuse.

Indeed, using #!/bin/sh in a script is a good habit, which can improve the adaptability between bsd/linux/mac, even powershell :laughing: