[Fixed] Issue "tcsetattr: Inappropriate ioctl for device" in script where curl used

[ZPMMaker]

I have a dozen remote RPi ZeroW's set up spread across a few countries, which I can control via SSH. They all have the RPi camera module v2 plugged in and have operated for about two years. They all run the same script every five minutes, which takes a photo and sends it to my server.

I did an apt-get update && apt-get upgrade about twelve hours ago on all of the systems.

Most of the systems still work fine, with my code unchanged. However, three systems are now having different issues, despite being set-up identically, and running the exact same software.

I already have a post about one of the three faulty systems (here: https://www.raspberrypi.org/forums/view ... 8&t=262642 ).

In this post, I'd like to troubleshoot a problem running cURL on two of the three faulty RPi's.

I'm using cURL to send data to a PHP server I have running on an AWS EC2 instance.

Long story short, the script takes a photo, renames it based on the template <systemID>_<YYYY><MM><DD>_<HH><mm>.jpg, converts it to WebP format using ImageMagick, and then uploads the WebP file to AWS S3. It then sends the filename to the PHP server using cURL so that the photo database running on the server is updated.

Here is a simplified test of cURL on this troublesome RPi:

Code: Select all

curl -X GET -G https://my.server.com/submit_image.php -d id=1 -d key=camImg/1/2020/01/22/id1_20200122_0630.webp

This returns the following error:

Code: Select all

bash: [8740: 3 (255)] tcsetattr: Inappropriate ioctl for device

...and the SQL database on the server also shows that the data was not sent to the server.


The same issue arises elsewhere in the same script, where I'm also using cURL, but to a different URL (a different server). This happens on a both of these two RPi's.

An example of the command issued:

Code: Select all

curl -X POST --data id="$ID" --data date="$date" --data statusCode="$1" --data message="$2" https://hook.server.com/34987yteungdf99w4otheg 

The variables $ID and $date are defined earlier in the script. This code is actually within a function. The function is called with two arguments (which are then passed to the cURL command to fill in $1 and $2).

If I try to use some dummy data, e.g.

Code: Select all

curl -X POST --data id="1" --data date="20200121" --data statusCode="69" --data message="Nice" https://hook.server.com/34987yteungdf99w4otheg 

....the same error occurs:

Code: Select all

bash: [10191: 3 (255)] tcsetattr: Inappropriate ioctl for device

This exact same code is running on ten other systems and is working perfectly fine there, and has done so for two years.

I tried reinstalling cURL:

Code: Select all

sudo apt purge curl

...but I got warning messages saying it'd uninstall a bunch of other vital programs, so I didn't proceed with removing and reinstalling cURL.

Any suggestions please on how to fix this?

Thanks in advance,
Dave

[jojopi]

The error message is from bash. It does not mention curl, nor give a script name or line number. Somehow bash thinks it is interactive at that point; it tries to set terminal attributes and finds it has no terminal. I am not sure what could cause that, but suspect it may involve command substitution ($(...) or `...`).

How are you determining that the message comes where the curl is used? Does it go away if you replace the curl command with just "echo curl", and do you see that message?

[ZPMMaker]

How are you determining that the message comes where the curl is used?

The camera script that runs via cron every five minutes calls a number of functions from a separate function.sh file.

Code: Select all

source /home/pi/functions.sh

When I SSH into an RPi and manually run the camera script, I get the following output:

Code: Select all

<messages that show the photo was taken correctly>
<message that shows the image was correctly compressed and converted to a different format>
<message that shows that the image was correctly uploaded to AWS S3>
/home/pi/functions.sh: line 121: 19569 Segmentation fault      curl -X GET -G https://URLto.myServer.com/submit_image.php -d id=$ID -d key=camImg/$ID/$DATEYYYY/$DATEMM/$DATEDD/$FILENAME.webp 
<a bunch of messages that show that the photo files were deleted as expected>

That seg-fault on line 121 of my functions.sh file (where the cURL command is) led me to manually run the cURL command in the OP for testing purposes, and that's when I realised cURL itself wasn't functioning correctly.

For what it's worth, the error message mentioned in the OP

bash: [8740: 3 (255)] tcsetattr: Inappropriate ioctl for device

...only appears if I manually run a cURL command myself. If I run my camera script instead, I don't get that error message, but instead, I get the seg-fault error as above.

Does it go away if you replace the curl command with just "echo curl", and do you see that message?

The segmentation fault error message does not appear if I comment-out that cURL command in my functions.sh script. If I add in

Code: Select all

echo "cURL command here"

just after that commented-out cURL command, that message does appear in stdout.

Thanks for your help and thoughts...
Dave

[ZPMMaker]

So I just tried to run

Code: Select all

sudo rpi-update

and got a segmentation fault error when rpi-update attempted to use cURL to download the updated version of rpi-update itself.

I decided to run

Code: Select all

sudo apt purge curl

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
dc g++-4.9 gir1.2-atk-1.0 gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-gmenu-3.0 gir1.2-gtk-3.0 gir1.2-pango-1.0
libasprintf0c2 libass5 libboost-filesystem1.55.0 libboost-program-options1.55.0 libboost-regex1.55.0 libchromaprint0
libcloog-isl4 libdc1394-22 libdca0 libdirectfb-1.2-9 libdvdnav4 libdvdread4 libelfg0 libenca0 libfaad2 libflite1 libglew1.10
libgme0 libgnome-menu-3-0 libgtkglext1 libisl10 libkate1 libmimic0 libmjpegutils-2.1-0 libmms0 libmodplug1
libmpeg2encpp-2.1-0 libmpg123-0 libmplex2-2.1-0 libntdb1 libofa0 liborcus-0.8-0 libpython3.4 libpython3.4-dev
libpython3.4-minimal libpython3.4-stdlib librtimulib-dev librtimulib-utils librtimulib7 libsoundtouch0 libspandsp2 libsrtp0
libstdc++-4.9-dev libswscale3 libtimedate-perl libvo-aacenc0 libvo-amrwbenc0 libwildmidi-config libwildmidi1 libwps-0.3-3
libzbar0 lxkeymap pix-icons pix-plym-splash pixel-wallpaper python-cairo python-chardet python-colorama python-dbus-dev
python-distlib python-gobject python-gobject-2 python-gtk2 python-html5lib python-ndg-httpsclient python-pyasn1
python-requests python-rtimulib python-sense-hat python-support python-urllib3 python-xklavier python3-rtimulib python3.4
python3.4-dev python3.4-minimal
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
curl* rpi-update* weavedconnectd*
0 upgraded, 0 newly installed, 3 to remove and 181 not upgraded.
After this operation, 361 kB disk space will be freed.
Do you want to continue? [Y/n]


(Reading database ... 125168 files and directories currently installed.)
Removing weavedconnectd (1.3-07z1) ...
Weaved daemon start/stop script Version: v1.5
Stopping Weavedrmt365535...
Weaved daemon start/stop script Version: v1.5
Stopping Weavedssh22...
Weaved server channel daemon start/stop script Version: v1.34
Stopping schannel.pi...
Removing rpi-update (20140705) ...
Removing curl (7.52.1-5+deb9u9) ...
Processing triggers for man-db (2.7.6.1-2) ...
(Reading database ... 125115 files and directories currently installed.)
Purging configuration files for weavedconnectd (1.3-07z1) ...

If you uninstalled weavedconnectd without first deleting your
devices and services, there may be orphaned devices or services
in your remot3.it account. Use the delete feature in remot3.it
to remove them from your account.
Processing triggers for systemd (215-17+deb8u13) ...
pi@raspberry:~ $

(Weaved was an old remote tunnelling for SSH client that I no longer use so I didn't mind that being uninstalled)

I then reinstalled curl and rpi-update:

Code: Select all

sudo apt-get curl rpi-update

I then rebooted and tried to run

Code: Select all

sudo rpi-update

again but once more I got a segmentation fault at the point when it was using cURL.

So despite reinstalling cURL, I'm still having this issue. Odd.

[jojopi]

Curl uses many shared libraries, so it is possible the segfault occurs inside one of them. See "ldd /usr/bin/curl".

You can reinstall a package without purging it first:

Code: Select all

sudo apt install --reinstall PACKAGE

However, if our working theory is that the SD card is experiencing corruption issues, then I do not think there is any guarantee we can resolve that using apt. Extensive rewriting may even move the problem to more important files, such that the system no longer boots.

You have similar systems that are still working, so I would suggest using tools like "md5sum" to narrow down which files are different.

I suspect that your application of processing image files hundreds of times a day for years is above average load for the SD card. You should consider preparing a good image on a new card, and arranging to do a straight card swap at the faulty location. That might ultimately be the required solution.

[DarkElvenAngel]

Just a suggestion if your problem is from SD card wear do to high writes, if you have enough ram free use a tmpfs for your image storage and processing. This will save you some headache.

[ZPMMaker]

Curl uses many shared libraries, so it is possible the segfault occurs inside one of them. See "ldd /usr/bin/curl".

You can reinstall a package without purging it first:

Code: Select all

sudo apt install --reinstall PACKAGE

However, if our working theory is that the SD card is experiencing corruption issues, then I do not think there is any guarantee we can resolve that using apt. Extensive rewriting may even move the problem to more important files, such that the system no longer boots.

You have similar systems that are still working, so I would suggest using tools like "md5sum" to narrow down which files are different.

I suspect that your application of processing image files hundreds of times a day for years is above average load for the SD card. You should consider preparing a good image on a new card, and arranging to do a straight card swap at the faulty location. That might ultimately be the required solution.

Just a suggestion if your problem is from SD card wear do to high writes, if you have enough ram free use a tmpfs for your image storage and processing. This will save you some headache.

Thanks for that suggestion. However, I have been using a tmpfs partition since day 1; all images are saved directly to that partition, converted to a different format and saved there, and then deleted from there. So all the camera functionality is done in RAM, not writing to the SD card at all.

That said, being two years old, the cards could have become corrupt due to age. However, given that two systems failed in the same manner at the same time, when ten others didn't, immediately after running apt-get upgrade, when everything else is (supposedly) identical... the chances of them both having an SD card that fails at the same command... seems incredibly unlikely. It seems more likely to me that there was an issue with the software update, rather than a hardware issue, especially given the fact that all my scripts run in a tmpfs rather than writing to the SD card.

Thanks for the suggestion for

Code: Select all

ldd /usr/bin/curl

and

Code: Select all

sudo apt install --reinstall PACKAGE

Would it be worthwhile trying to reinstall all the packages that the ldd command lists? I realise that this would involve a lot of writing to the SD card which may make things worse.

I just wondered if there is any way of testing the SD card prior to trying to reinstall the packages. A quick Google found this: https://www.tecmint.com/check-linux-har ... ad-blocks/

Code: Select all

sudo badblocks -v /dev/mmcblk0p2 > /home/pi/badsectors.txt

...which seems to try to read all the sectors on the disk without overwriting them.
I'm now running that command to check for bad sectors. Looks like it'll take a while.
Update: this command output the following after completion on both RPi's:

Checking blocks 0 to 15512063
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found. (0/0/0 errors)

Update2: I did the same on all my RPi's and got the same result.

So that doesn't seem to think there's anything wrong with the SD card.
Of course, that's just doing read tests, not write tests, so that doesn't necessarily exclude the possibility of a corrupted SD card.

Is there any other way I can test the disk for corruption, preferably remotely without involving anyone else (I try to minimise how many times I ask the locals for help as they're all volunteers...)?

jojopi, could you please provide an example of how I should use md5sum to figure out what files are different between the Pi's? I thought md5sum was used for checking the authenticity of downloaded files?

Thanks for the advice and help.
Dave

[jojopi]

'badblocks" is not as relevant as it was decades ago. Operating systems used to need facilities to find and work around defects in the media. All modern storage devices do this internally, and hide problems from the OS until they lose data. The fact that you can read the whole card is not a bad sign, but it does not mean there are no problems.

I was thinking you might run "md5sum *" on the good and bad machines and compare the outputs. However, since we are mainly concerned with files that are managed by apt/dpkg, there is a tool to check the files against the package info, and you do not even need a known-good machine:

Code: Select all

sudo apt install debsums
sudo debsums -c

This should (eventually) list any non-configuration files whose checksums do not match the version that was supposed to be installed. Use "dpkg -S FILE" to check which packages any such files belong to, and reinstall those packages.

[DarkElvenAngel]

This is something that maybe worth looking at. You said these in the initial post

I have a dozen remote RPi ZeroW's set up spread across a few countries, which I can control via SSH.

Then I got to thinking maybe your pulling software from a bad mirror since it could be possible they would use different ones. Have you seen any pattern as to the units failed and location? You could check the checksums of curl and it's dependencies on a good vs affected unit.
Then if you have a mismatch secure copy (scp) replacements from your known working to the affected unit and see if it works.

[jojopi]

Then I got to thinking maybe your pulling software from a bad mirror since it could be possible they would use different ones.

Repository data is cryptographically signed to guard against tampering. apt will not install anything unless it can verify that the exact package file was approved by one of the two keys it trusts (Raspbian Project or Raspberry Pi Archive).

A bad mirror can stop apt from working for a time, but it cannot break your system.

[DarkElvenAngel]

Then I got to thinking maybe your pulling software from a bad mirror since it could be possible they would use different ones.

Repository data is cryptographically signed to guard against tampering. apt will not install anything unless it can verify that the exact package file was approved by one of the two keys it trusts (Raspbian Project or Raspberry Pi Archive).

A bad mirror can stop apt from working for a time, but it cannot break your system.

I was not referring to corrupted packages but to outdated or slow mirrors.

I think it's a safe course of action to preform checksums on curl and it dependencies and verify they are correct against a working system. If something isn't a match copying working versions should repair the issue.

[ZPMMaker]

'badblocks" is not as relevant as it was decades ago. Operating systems used to need facilities to find and work around defects in the media. All modern storage devices do this internally, and hide problems from the OS until they lose data. The fact that you can read the whole card is not a bad sign, but it does not mean there are no problems.

I was thinking you might run "md5sum *" on the good and bad machines and compare the outputs. However, since we are mainly concerned with files that are managed by apt/dpkg, there is a tool to check the files against the package info, and you do not even need a known-good machine:

Code: Select all

sudo apt install debsums
sudo debsums -c

This should (eventually) list any non-configuration files whose checksums do not match the version that was supposed to be installed. Use "dpkg -S FILE" to check which packages any such files belong to, and reinstall those packages.

Thanks for the advice, jojopi and DarkElvenAngel.

I ran the debsums -c command on both of the Pi's that can't use curl. After about 30mins, the terminal returned to the prompt without any output, so presumably it didn't find any files with non-matching checksums.

However, I also ran the command on my other faulty Pi (the one that's able to use curl, but thinks the camera module is unplugged, as discussed over at: https://www.raspberrypi.org/forums/view ... 2#p1599222), and that resulted in a list of 71 files, including part of raspistill and rpi-update(!). I will post a comment explaining this and the result of the dpkg -S command over in that thread shortly rather than derailing this discussion, but it's interesting that found anything.

Sadly, it doesn't seem to be the problem with these two systems that can't use curl....

I had a quick look at the man page for debsums (well, as much as I could see of it due to this other issue: https://www.raspberrypi.org/forums/view ... 3#p1599693), and I noticed the -a and -l options, and figured I'd give sudo debsums -al a whirl on both systems that can't run curl. Again, no output whatsoever.

Finally, I tried sudo debsums -a. This output a very, very long list of files with "[OK]" next to each one. So presumably, there's nothing wrong there...

Thanks for your help and advice.
Dave

[ZPMMaker]

I decided to re-run that debsums -a command, but redirected stdout to a file so I could grep -v OK ~/debsums-a.txt and be more thorough, rather than just quickly scrolling through the output with my mouse.

This was most wise. I had missed a few things that weren't ok.

On system A:

Code: Select all

/etc/skel/.bashrc                                                         FAILED
/etc/dhcpcd.conf                                                          FAILED
/etc/lightdm/lightdm.conf                                                 FAILED
/etc/default/useradd                                                      FAILED
/etc/plymouth/plymouthd.conf                                              FAILED

On system B:

Code: Select all

/etc/skel/.bashrc                                                         FAILED
/etc/lightdm/lightdm.conf                                                 FAILED
/etc/default/useradd                                                      FAILED
/etc/plymouth/plymouthd.conf                                              FAILED

On system A, I ran the following:

Code: Select all

dpkg -S /etc/skel/.bashrc
bash: /etc/skel/.bashrc

Code: Select all

dpkg -S /etc/dhcpcd.conf
dhcpcd5: /etc/dhcpcd.conf

Code: Select all

dpkg -S /etc/lightdm.conf
dpkg-query: no path found matching pattern /etc/lightdm.conf

Code: Select all

dpkg -S /etc/default/useradd
passwd: /etc/default/useradd

Code: Select all

dpkg -S /etc/plymouth/plymouthd.conf
plymouth: /etc/plymouth/plymouthd.conf

...followed by...

Code: Select all

sudo apt install --reinstall bash dhcpcd5 passwd plymouth

And here's the output of that, so far:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
dc g++-4.9 gir1.2-atk-1.0 gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-gmenu-3.0 gir1.2-gtk-3.0 gir1.2-pango-1.0 libalgorithm-c3-perl libarchive-extract-perl libasprintf0c2 libass5 libboost-filesystem1.55.0
libboost-program-options1.55.0 libboost-regex1.55.0 libcgi-fast-perl libcgi-pm-perl libchromaprint0 libclass-c3-perl libclass-c3-xs-perl libcloog-isl4 libcpan-meta-perl libdata-optlist-perl libdata-section-perl libdc1394-22 libdca0
libdirectfb-1.2-9 libdvdnav4 libdvdread4 libelfg0 libenca0 libfaad2 libfcgi-perl libflite1 libglew1.10 libgme0 libgnome-menu-3-0 libgtkglext1 libisl10 libjim0.75 libkate1 liblog-message-perl liblog-message-simple-perl libmimic0
libmjpegutils-2.1-0 libmms0 libmodplug1 libmodule-build-perl libmodule-pluggable-perl libmodule-signature-perl libmpeg2encpp-2.1-0 libmpg123-0 libmplex2-2.1-0 libmro-compat-perl libntdb1 libofa0 liborcus-0.8-0 libpackage-constants-perl
libparams-util-perl libpod-latex-perl libpod-readme-perl libpython3.4 libpython3.4-dev libpython3.4-minimal libpython3.4-stdlib libregexp-common-perl librtimulib-dev librtimulib-utils librtimulib7 libsoftware-license-perl libsoundtouch0
libspandsp2 libsrtp0 libstdc++-4.9-dev libsub-exporter-perl libsub-install-perl libswscale3 libterm-ui-perl libtext-soundex-perl libtext-template-perl libtimedate-perl libvo-aacenc0 libvo-amrwbenc0 libwildmidi-config libwildmidi1
libwps-0.3-3 libzbar0 lxkeymap pix-icons pix-plym-splash pixel-wallpaper python-cairo python-chardet python-colorama python-dbus-dev python-distlib python-gobject python-gobject-2 python-gtk2 python-html5lib python-ndg-httpsclient
python-pyasn1 python-requests python-rtimulib python-sense-hat python-support python-urllib3 python-xklavier python3-rtimulib python3.4 python3.4-dev python3.4-minimal
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
ifupdown init-system-helpers keyutils libfdisk1 libip4tc0 libjim0.76 libpam-systemd libseccomp2 libsystemd0 libudev1 nfs-common plymouth-themes systemd sysvinit-utils udev usb-modeswitch util-linux
Suggested packages:
ppp rdnssd open-iscsi watchdog systemd-ui systemd-container comgt wvdial util-linux-locales
The following NEW packages will be installed:
keyutils libfdisk1 libip4tc0 libjim0.76 libseccomp2
The following packages will be upgraded:
ifupdown init-system-helpers libpam-systemd libsystemd0 libudev1 nfs-common plymouth plymouth-themes systemd sysvinit-utils udev usb-modeswitch util-linux
13 upgraded, 5 newly installed, 3 reinstalled, 0 to remove and 156 not upgraded.
Need to get 6,461 kB/8,858 kB of archives.
After this operation, 1,308 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Err:1 http://mirrordirector.raspbian.org/raspbian stretch/main armhf libfdisk1 armhf 2.29.2-1+deb9u1
Temporary failure resolving 'mirrordirector.raspbian.org'
Err:2 http://archive.raspberrypi.org/debian stretch/ui armhf plymouth armhf 0.9.2-4+rpi1
Temporary failure resolving 'archive.raspberrypi.org'
Err:3 http://mirrordirector.raspbian.org/raspbian stretch/main armhf init-system-helpers all 1.48
Temporary failure resolving 'mirrordirector.raspbian.org'
Err:4 http://archive.raspberrypi.org/debian stretch/ui armhf plymouth-themes armhf 0.9.2-4+rpi1
Temporary failure resolving 'archive.raspberrypi.org'
Err:5 http://mirrordirector.raspbian.org/raspbian stretch/main armhf util-linux armhf 2.29.2-1+deb9u1
Temporary failure resolving 'mirrordirector.raspbian.org'
Err:6 http://mirrordirector.raspbian.org/raspbian stretch/main armhf sysvinit-utils armhf 2.88dsf-59.9
Temporary failure resolving 'mirrordirector.raspbian.org'
Err:7 http://mirrordirector.raspbian.org/raspbian stretch/main armhf libip4tc0 armhf 1.6.0+snapshot20161117-6
Temporary failure resolving 'mirrordirector.raspbian.org'
Err:8 http://mirrordirector.raspbian.org/raspbian stretch/main armhf libseccomp2 armhf 2.3.1-2.1+deb9u1
Temporary failure resolving 'mirrordirector.raspbian.org'
25% [Working]

It has been stuck on 25% for about ten minutes now.

Interesting that it is coming back with "Temporary failure resolving 'mirrordirector.raspbian.org'". I'm guessing this means the Pi can't connect to the Raspbian server/package repo?

Is there a way of fixing this?

[rpdom]

Interesting that it is coming back with "Temporary failure resolving 'mirrordirector.raspbian.org'". I'm guessing this means the Pi can't connect to the Raspbian server/package repo?

It means the Pi can't find out the IP address to use for the server 'mirrordirector.raspbian.org' with a DNS lookup. Something is wrong with the DNS settings for that Pi.

[ZPMMaker]

Interesting that it is coming back with "Temporary failure resolving 'mirrordirector.raspbian.org'". I'm guessing this means the Pi can't connect to the Raspbian server/package repo?

It means the Pi can't find out the IP address to use for the server 'mirrordirector.raspbian.org' with a DNS lookup. Something is wrong with the DNS settings for that Pi.

Beauty, thanks. I ran sudo nano /etc/resolv.conf, and changed the nameserver field to 8.8.8.8 (Google's DNS IP), then re-ran the reinstall command, and it seems to be working now.

Will update this thread once everything is reinstalled and I can test out curl.

Cheers,
Dave

[ZPMMaker]

Interesting that it is coming back with "Temporary failure resolving 'mirrordirector.raspbian.org'". I'm guessing this means the Pi can't connect to the Raspbian server/package repo?

It means the Pi can't find out the IP address to use for the server 'mirrordirector.raspbian.org' with a DNS lookup. Something is wrong with the DNS settings for that Pi.

Beauty, thanks. I ran sudo nano /etc/resolv.conf, and changed the nameserver field to 8.8.8.8 (Google's DNS IP), then re-ran the reinstall command, and it seems to be working now.

Will update this thread once everything is reinstalled and I can test out curl.

Cheers,
Dave

cURL commands are still seg-faulting, sadly...

[ZPMMaker]

OK, major derp moment.

I just realised I'm still running Stretch rather than Buster.

Just did sudo apt full-upgrade and that completely fixed one of the two faulty systems.

Will try and do this on the other one tomorrow (it's almost midnight here now). Will keep the thread updated as I make progress...

Thanks!

[ZPMMaker]

OK, major derp moment.

I just realised I'm still running Stretch rather than Buster.

Just did sudo apt full-upgrade and that completely fixed one of the two faulty systems.

Will try and do this on the other one tomorrow (it's almost midnight here now). Will keep the thread updated as I make progress...

Thanks!

Yup, both systems fixed by running sudo apt full-upgrade. Haven't done the full distro upgrade to Buster as yet; will give that a go at a later date, but for now, these two systems and the cURL issue seems to be fixed.

Thanks everyone for your help!