Skip to main content

The “/usr/local/cpanel/scripts/rdate” command reported error number 4 when it ended

Answered

Comments

16 comments

  • Andrew

    I bet it's your resolvers. Adjust your /etc/resolv.conf file to include Google's nameservers:

    nameserver 8.8.8.8
    nameserver 8.8.4.4

    Andrew N. - cPanel Plesk VMWare Certified Professional
    Do you need immediate assistance? 20 minutes response time!* Open a ticket
    EmergencySupport - Professional Server Management and One-time Services

    0
  • cPRex Jurassic Moderator

    What happens if you manually run the rdate command on the system?

    0
  • Earl Grey

    rdate doesn't appear to be installed:

    rdate -s rdate.cpanel.net
    bash: rdate: command not found

    timedatectl works and time & timezone is correct (Australia)

    Should rdate be installed? Will it conflict with timedatectl, if so, does this need to be removed?

    0
  • cPRex Jurassic Moderator

    Yes, I would expect that to be installed on most servers.  I'd just install it and that should take care of everything.

    0
  • mtindor

    I wouldn't inspect installing rdate to fix anything.  cPanel uses /usr/local/cpanel/scripts/rdate

    /usr/local/cpanel/scripts/rdate -p
    rdate: [rdate.cpanel.net]       Wed Apr 17 06:24:51 2024

    So I believe rdate is accessible but that you are still blocked by your firewall.

    I run CSF firewall on my servers, and in my TCP_OUT section I have 37 listed as one of the ports to allow outbound access to.   In the actual /usr/local/cpanel/scripts/rdate script, it shows that it uses TCP 37 outbound.

    If you are using CSF, edit the TCP_OUT line in your /etc/csf/csf.conf file to include 37 and then do a 'csf -r'.  Or log into WHM --> Plugins --> ConfigServer Security & Firewall and edit the conf file and restart that way.

    If you are only using IPTABLES, then I can't help you since I have no idea what all of your active IPTABLES rules look like.

     

    0
  • cPRex Jurassic Moderator

    Good catch, mtindor - *our* rdate package is unrelated to the system rdate package.

    Please try and manually run *exactly the command that failed*

    /usr/local/cpanel/scripts/rdate

    0
  • Earl Grey

    Same error as the cpanel update script:

    /usr/local/cpanel/scripts/rdate
    Failed to run due to the 10 second timeout being exceeded.

    There's a hardware firewall in front of the server, but that hasn't changed since the swap from CentOS to Alma, so that shouldn't be the problem. It's not running a software firewall, so I'm expecting IP tables is the problem, however I get this:

    # iptables -L output
    iptables v1.8.8 (nf_tables): chain `output' in table `filter' is incompatible, use 'nft' tool.

    I found some doco on cpanel site that says NFT runs the iptables for AlmaLinux. It looks like the cpanel reseller didn't setup the cpanel recommended rules from this article (I will contact them and see if they know about it):

    https://docs.cpanel.net/knowledge-base/general-systems-administration/how-to-configure-your-firewall-for-cpanel-services/

    The cpanel service

    Important:

    The /usr/local/cpanel/scripts/configure_firewall_for_cpanel script clears all existing rule entries from your server’s iptables utility. If you use custom rules for your firewall, export those rules before you run the script and then re-add them afterward.

    cPanel & WHM also includes the cpanel service, which manages all of the rules in the /etc/firewalld/services/cpanel.xml file. This allows TCP access for the server’s ports.

    To replace your server’s existing iptables rules with the rules in the /etc/firewalld/services/cpanel.xml file, perform the following steps:

    1. Run the yum install firewalld command to ensure that you have installed the firewalld service daemon on your system.
    2. Run the systemctl start firewalld.service command to start the firewalld service.
    3. Run the systemctl enable firewalld command to start the firewalld service when the server starts.
    4. Run the iptables-save > backupfile command to save your existing firewall rules.
    5. Run the /usr/local/cpanel/scripts/configure_firewall_for_cpanel script.
    6. Run the iptables-restore < backupfile command to incorporate your old firewall rules into the new firewall rules file.
    1
  • cPRex Jurassic Moderator

    Is port 37 outbound open?

    0
  • cPRex Jurassic Moderator

    The following test would help to confirm that, if you have telnet installed:

    telnet rdate.cpanel.net 37
    0
  • Earl Grey

    No, it times out, but it could be return inbound that's a problem as well. Unlikely that the hardware firewall is blocking it, as cpanel updates always worked on the CentOS server that this replaced and this is using the same IP address as the old one.

    # telnet rdate.cpanel.net 37
    Trying 208.74.121.43...

    0
  • cPRex Jurassic Moderator

    A smarter person than me told me "never come up with reasons not to test something."

    There's *something* blocking the connection so something has changed, you'll just need to track down where that is.

    0
  • Earl Grey

    The reseller has changed the hardware firewall and says that the test rdate cmd is now working. They say that there were no changes to the firewall, so can only assume that rdate has been added to the latest cpanel update script. Does this sound correct to you?

    0
  • mtindor

    cpRex is more qualified to answer that than I.   But I call that a bunch of hogwash.   I seriously doubt the rdate script was just added.    You couldn't "telnet rdate.cpanel.net 37" before and get response but I'm guessing you can now.   That has nothing to do with rdate being on the server or not.   that is purely a firewall thing.

    0
  • cPRex Jurassic Moderator

    100% a firewall issue, like you've already found.  The rdate call has been inside cPanel for many years.

    0
  • Earl Grey

    Resolved - Thank you all for your help.

    0
  • cPRex Jurassic Moderator

    You're very welcome!

    0

Please sign in to leave a comment.