After 10.8 Upgrade, Getting Cron Daemon emails daily

[Ben Erickson]

After upgrading to SMG 10.8, I'm getting this email once a day, every day, from the SMG Cron Daemon. The error message seems to be informational, not a warning or an error. I have rebooted but this made no difference. Current software version: 10.8.0-7

* About to connect() to tmsg.symantec.com port 443 (#0)
* Trying 141.202.0.16...
* Connected to tmsg.symantec.com (141.202.0.16) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /data/scanner/etc/trusted.cert
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=eapi.broadcom.com,O=Broadcom Inc,L=San Jose,ST=California,C=US
* start date: Jan 27 00:00:00 2022 GMT
* expire date: Dec 17 23:59:59 2022 GMT
* common name: eapi.broadcom.com
* issuer: CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1,O=DigiCert Inc,C=US
> POST /msgtel HTTP/1.1
User-Agent: tmagent;smgapp_10.8.0-351;SMSA v10.8.0;linux.x86_64;vmapp
Host: tmsg.symantec.com
Accept: */*
Content-Length: 2934
Expect: 100-continue
Content-Type: multipart/form-data; boundary=----------------------------ed619d823c9c

< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< date: Sun, 30 Oct 2022 01:16:02 GMT
< content-type: application/json
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< cache-control: no-cache, no-store, max-age=0, must-revalidate
< pragma: no-cache
< expires: 0
< x-request-id: 324a7aa9-af30-47bf-a8b8-e1f1df940111
< transfer-encoding: chunked
< Via: 1.1 google
< Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
<
* Connection #0 to host tmsg.symantec.com left intact

[Art_P]

Here you go:
Unexpected email messages from Cron Daemon after upgrade to Messaging Gateway 10.8.0

------------------------------
---------------------------------------------
Support Engineer
* Integrated Cyber Defense Exchange
* Messaging Gateway
* Packet Shaper
Symantec Enterprise Division
Broadcom Software
------------------------------

[Ben Erickson]

Ok, thanks- so "known issue". Is there a workaround? I'm comfortable in the command line.

[Art_P]

Sorry, I missed your response due to other non-related posts. There is no workaround, aside from filtering these messages out at another point (like mail server or email client), but the patch to resolve this should be released very soon.

------------------------------
---------------------------------------------
Support Engineer
* Integrated Cyber Defense Exchange
* Messaging Gateway
* Packet Shaper
Symantec Enterprise Division
Broadcom Software
------------------------------

[alexander-smg]

Dnssec don’t work in 10.8

The hosts dns feature don’t work in 10.8 either.

Oh no.

[Ben Erickson]

Maybe you rushed them to release too soon, Alex! ;-)

[alexander-smg]

No. I asked for those features two years ago. And they have documentation on them either. Yuk.

[Ben Erickson]

When is version 11 coming?

[alexander-smg]

Never

[Art_P]

Hello Alexander,
The support team hasn't seen other reports similar to yours. Please open a case with further detail of what you are experiencing so we can help you.
In regards to product features, it would be best to work with your sales team and the Product Manager to better understand what you would like in the product.

------------------------------
---------------------------------------------
Support Engineer
* Integrated Cyber Defense Exchange
* Messaging Gateway
* Packet Shaper
Symantec Enterprise Division
Broadcom Software
------------------------------

[alexander-smg]

There is no documentation for this feature in 10.8 ? Why?

[Thomas Anderson]

There should be context sensitive help and documentation available regarding DNSSEC.
We have identified a bug in the help system that, under some circumstances, it presents a blank page.
The fix for that issue is included in the upcoming patch that Art mentioned above.
The patch is currently in the testing phase,

[alexander-smg]

The dns host feature don’t work.

[Erhan Acik]

I have the same problem, it sends warning emails several times a day, sometimes in the middle of the night. and there are no rules about it.

[alexander-smg]

On 10.8 I keep getting backup failed and sometimes the backup actually worked. And other times the backups actually do fail. And in 10.8, my idea (yes my idea) for policies groups for outbound versus inbound is now a “OR”. Arg. I wanted “And”. Worst of all, the setting is barried under settings, not policy groups.. very very bad

[Erhan Acik]

We had the same problem, after the update the backups did not work.

After changing the backup date and time, our problem was solved.

[alexander-smg]

I did all that, still issues.

[Ben Erickson]

Thanks for mentioning that. I didn't notice, but my backups were silently failing as well. I've reverted back to 10.7.5. Version 10.8 is obviously not ready for prime time. The irony of it is that I was getting useless crond messages in my inbox about a non-issue but then when backups aren't running, well, radio silence. Crickets.

I miss the good old days when software was properly tested by humans in a production-like environment before it was released instead of automated testing that misses stuff like this.

[alexander-smg]

I am still waiting for a patch.

[Ben Erickson]

Really?

[alexander-smg]

Yah really!

[alexander-smg]

And they ain’t cron messages. They are failed backup messages.

[Ben Erickson]

Check my original post. It's about an HTTP connection from SMG to a Broadcom server.

[alexander-smg]

Need a patch

[Numan Firat]

Hi Ben,

I'd like to go back to 10.7.5 as I've had a few different issues.
How can I downgrade? When I try via CLI, I get the output with the new version already installed.

Thanks for your ideas,

[alexander-smg]

U need to format in order to redue. If it’s vm, just override.

[Numan Firat]

Thank you,

[Ben Erickson]

In my case, I back up an image every night of the virtual machine. I just restored it to the night before the upgrade. Without that, you could copy your last working database backup from 10.7.5 (not hard since the backups fail on 10.8) off host, format and reinstall the OS, then restore the database.

[alexander-smg]

Cool

[Ben Erickson]

duplicate

[Geogie George]

There is a workaround for the scheduled backup issue. Please follow the below KB link

Messaging Gateway Alert - Scheduled tasks failures after upgrade to 10.8.0

Broadcom		remove preview
Messaging Gateway Alert - Scheduled tasks failures after upgrade to 10.8.0 Following the upgrade to Messaging Gateway 10.8.0, scheduled backups fail with the following errors logged in the BrightmailLog.log Nov 14 2022 00:00:00 [Bright View this on Broadcom >

[alexander-smg]

Page not found. Paste the link the again

[Geogie George]

Messaging Gateway Alert - Scheduled tasks failures after upgrade to 10.8.0

Broadcom		remove preview
Messaging Gateway Alert - Scheduled tasks failures after upgrade to 10.8.0 Following the upgrade to Messaging Gateway 10.8.0, scheduled backups fail with the following errors logged in the BrightmailLog.log Nov 14 2022 00:00:00 [Bright View this on Broadcom >

Please follow this link.

[alexander-smg]

This is a known issue and will be addressed with a future release.

And workaround fails.

LOL

[James Martini]

Hello Alex,

I did the original investigation of the scheduled backup issue and penned the KB. The instructions have been 100% effective in customer cases experiencing the DNS resolution based issue if followed to the letter. Most commonly, customers skip the system restart but this is an essential step as a restart of the osconfig service is required to updated the hosts file on the system.

If you've added the hostname to IP mapping and restarted the Control Center VM / appliance but are still seeing a failure, there may be another issue separate from the DNS resolution one and I encourage you to open a support case for investigation.

Specifically, if you have changed the IP of the Control Center VM / appliance but not updated the agent service access control list (ACL) to reflect that IP change, this can also impact some Control Center operations.

[alexander-smg]

So you are saying that my dns enhancement causes backups to fail. Oh no.
On Dec 6, 2022, at 11:54 AM, James Martini via Broadcom <[e-mail]> wrote:

Hello Alex, I did the original investigation of the scheduled backup issue and penned the KB. The instructions have been 100% effective in... -posted to the "Messaging Gateway" community <https: community.broadcom.com=""> Messaging Gateway <https: community.broadcom.com/symantecenterprise/communities/community-home/digestviewer?communitykey="bba1e9dc-0c56-4fb5-9e3d-ef7f0d79b7ee"> Post New Message <[e-mail]> Re: After 10.8 Upgrade, Getting Cron Daemon emails daily <https: community.broadcom.com/symantecenterprise/discussion/after-108-upgrade-getting-cron-daemon-emails-daily#bm747c7d42-7cf1-4c7d-a893-0184e896991c=""> Reply to Group <[e-mail]?subject=re: after="" 10.8="" upgrade,="" getting="" cron="" daemon="" emails="" daily=""> Reply to Sender <https: community.broadcom.com/symantecenterprise/communities/all-discussions/postreply?messagekey="747c7d42-7cf1-4c7d-a893-0184e896991c&ListKey=c7074c2b-e593-418f-9d9e-0567f9e41e52&SenderKey=a7a0b180-8ca1-44ad-b323-3c100c529e3c"> <https: community.broadcom.com/network/members/profile?userkey="a7a0b180-8ca1-44ad-b323-3c100c529e3c"> Dec 6, 2022 11:47 AM James Martini <https: community.broadcom.com/network/members/profile?userkey="a7a0b180-8ca1-44ad-b323-3c100c529e3c"> Hello Alex,

I did the original investigation of the scheduled backup issue and penned the KB. The instructions have been 100% effective in customer cases experiencing the DNS resolution based issue if followed to the letter. Most commonly, customers skip the system restart but this is an essential step as a restart of the osconfig service is required to updated the hosts file on the system.

If you've added the hostname to IP mapping and restarted the Control Center VM / appliance but are still seeing a failure, there may be another issue separate from the DNS resolution one and I encourage you to open a support case for investigation.

Specifically, if you have changed the IP of the Control Center VM / appliance but not updated the agent service access control list (ACL) to reflect that IP change, this can also impact some Control Center operations. Reply to Group Online <https: community.broadcom.com/symantecenterprise/communities/all-discussions/postreply?messagekey="747c7d42-7cf1-4c7d-a893-0184e896991c&ListKey=c7074c2b-e593-418f-9d9e-0567f9e41e52"> Reply to Group via Email <[e-mail]?subject=re: after="" 10.8="" upgrade,="" getting="" cron="" daemon="" emails="" daily=""> View Thread <https: community.broadcom.com/symantecenterprise/discussion/after-108-upgrade-getting-cron-daemon-emails-daily#bm747c7d42-7cf1-4c7d-a893-0184e896991c=""> Recommend <https: community.broadcom.com:443/symantecenterprise/discussion/after-108-upgrade-getting-cron-daemon-emails-daily?messagekey="747c7d42-7cf1-4c7d-a893-0184e896991c&cmd=rate&cmdarg=add#bm747c7d42-7cf1-4c7d-a893-0184e896991c"> Forward <https: community.broadcom.com/symantecenterprise/communities/all-discussions/forwardmessages?messagekey="747c7d42-7cf1-4c7d-a893-0184e896991c&ListKey=c7074c2b-e593-418f-9d9e-0567f9e41e52"> Flag as Inappropriate <https: community.broadcom.com/symantecenterprise/discussion/after-108-upgrade-getting-cron-daemon-emails-daily?markappropriate="747c7d42-7cf1-4c7d-a893-0184e896991c#bm747c7d42-7cf1-4c7d-a893-0184e896991c">

[James Martini]

Following some code changes in 10.8.0, some operations in the Control Center web application connect to the agent on the Control Center VM on the eth0 IP address rather than localhost as was the case previously. This has caused some issues where either the SMG Control Center IP has changed without updating the agent ACL or where the SMG hostname is unresolvable in the DNS. 

The issue with hostname resolution will be addressed in a future release or patch but, for now, the workaround is to add a hostname to IP mapping in the Administration > DNS / Time config for the Control Center host.

The ability to add entries to hosts file gives us a means of working around the DNS resolution issue but wasn't the cause.

So your enhancement request wasn't the cause of the issue but, rather, the path to a workaround.

If you're still having issues with the scheduled backups following a restart of the SMG Control Center host / vm, please open a support case and we'll have a look.

[Jim Wallis]

I have been getting the daily cron message, and because it didn't appear to be flagging an actual problem I had assumed it was just an increase in verbosity from the update, but now you have me wondering about failed backups.

So I think I've been through all the dashboard options and logs and I don't see anywhere that it tells me about backup succcess or failure - what am I missing, how do I check backup status?

(Not a pro, just the guy in a small business who also does the IT)

[James Martini]

Hello Jim,

The message from the cron daemon has been addressed with SMG patch 10.8.0-293. You can find instructions for applying the patch at Installing and removing patches for Messaging Gateway.

In general, I try to keep an index of emerging issues with the various SMG releases in that version's Late Breaking News and Release Notes KB so that's often a good place to look first if you start experiecing some new problem following an update. 

The underlying issue with the cron emails is that previously output from the cron daemon was discarded. In 10.8.0 we enabled the cron daemon's ability to send job output (usually errors) as email which is the standard for the linux os. Unfortunately, one of the scripts generates output to stdout as part of it's normal operation so it generated a cron email with every run. We corrected the script's output with the 10.8.0-293 patch but any other error conditions will still be reported by cron via an email alert.

The scheduled backup success or failure can be found in Status > Scheduled Tasks > Backups

Thank you,

James Martini

[alexander-smg]

Nothing has worked for me. It all fails. L

[James Martini]

Hello Alex,

If you're still seeing alert messages from cron following the patch or are still seeing issues with the scheduled backups / task, please open a support case. So far, correcting the name resolution for the SMG control center hostname has addressed the scheduled backup issue in all cases but there may be something unique to your environment which isn't accounted for in the KB.

Thanks,

James

[Jim Wallis]

I applied the patch this morning, I will find out tomorrow if it has worked for me or not with regard to the cron message, the main thing is that as I thought, it is not telling me that anything is wrong.

I found I had alerts for backups turned off and as soon as I turned it on I received an alert, and following your instructions I have also confirmed that in control centre now. This is not a critical issue for me so I will look into it later, maybe tomorrow. I did note the information above about DNS / IP resolution issues and neither IP or hostname for this VM have changed since it was installed so that seems unlikely to be the issue, I am storing the backups by ftp on a linux server addressed by IP address so there could be a problem with that (but shouldn't be as it has the IP), or it could be an issue with DNS which is on my AD DC which you will see from my new thread about it I have DDS problems performing LDAP lookups against since the update, which may be update related, or just heavy brute force attack load. So even though SMG DNS details have not changed, there may be a DNS connection issue with the DC as well as an LDAP issue. But I'm UK based and finishing for today.

[James Martini]

Hello Jim,

Please see Messaging Gateway Alert - Scheduled tasks failures after upgrade to 10.8.0. While the hostname and IP of the SMG Control Center have not changed, the mechanism by which the Control Center determines where to connect to kick off the scheduled task has. Previously all connections were to the localhost interface but now the Control Center does name resolution on the hostname configured in Administration > Configuration for the control center host. If that returns an incorrect or null value the Control Center web application cannot initiate the backup.

The change was required for the addition of the Dedicated Quarantine role but in environments where the hostname of the SMG system is not resolvable some operations may fail including some scheduled tasks. If you continue to have issues with the scheduled tasks, please don't hesitate to open a support case and I or one of my peers will work with you to address the problem.

Thank you,

James Martini

[Jim Wallis]

Firstly, the patch does indeed seem to have stopped the daily email from cron, although I note that I now have a 4am warning that conduit has stopped (but was running again by the time I checked at 9am) as Alexander describes.

Looking at the KB for the scheduled task failure, I do see the errors noted in brightmaillog.log, plus some other scheduled task failures (looks like failure to send me some reports, which may be down the LDAP issues, or the hostname issue). I presume SMG uses cron as its task scheduler so maybe these issues are not unrelated?

I configured my SMG system with 2 IP addresses, I can't remember why now.
XXX.XXX.XXX.11 is the inbound address and the  address I connect to the control centre and for SMTP authentication
XXX.XXX.XXX.12 is the the outbound address and the address that is used for the LDAP connection
The second is a virtual IP assigned to the same interface as the first.

Which address needs to be reolvable by the control centre, I am presuming .11 since that is the address I use to connect it and we are explicitly redefining localhost? That is the address the DC returns if I do an nslookup for the hosts FQDN.

And of course I still have DDS issues randomly stopping mail from being sent, which is much more critical than the backup, which given that our queue normally empties immediately is only really a settings backup.

Thanks

[alexander-smg]

I am still getting errors

[Ben Erickson]

Are you guys all opening up tickets?

As I stated earlier, I rolled back to 10.7.5 and will stay there until it's all ironed out because my gut tells me this is more of a management problem at this point than a technical problem. But the more tickets there are of those of you sticking with 10.8, the more this will grab their attention. Especially LINGERING tickets that never get closed because the patches don't fix the original problem.

[alexander-smg]

Oh brother.

[James Martini]

Hello Ben,

If application of patch 10.8.0-293 does not resolve the issue with alerts from the cron daemon for the nightly telemetry upload, we absolutely encourage our customers to open a support case so that the issue may be investigated and resolved. 

The failure of scheduled tasks which has also been raised in this thread is not addressed by patch 10.8.0-293. In most cases, that issue is caused the SMG hostname not being resolvable in the DNS and may be addressed via Messaging Gateway Alert - Scheduled tasks failures after upgrade to 10.8.0. If there are instances where this solution is not effective, we want to identify them so that the KB can be updated and the problem addressed with the next release or patch.

Additionally, if the Control Center has had its IP changed and the agent access control list has not been updated, that can also cause scheduled tasks to fail as well but for a different reason than above.

Thank you,

James Martini

[alexander-smg]

Yah the feature I asked for a year ago is now needed to fix another issue. Lol. Yes I asked for the dns host feature. Lol

[James Martini]

Hello Jim,

If you continue to see alerts from cron after application of patch 10.8.0-293 or questions regarding the configuration of the name resolution of the SMG hostname, please open a support case. I can gurantee you that my team can sort out the issue faster than a forum thread.

Regarding the scheduled task, the hostname of the SMG system set in Administration > Configuration needs to resolve to one or both of the configured IP addresses for the SMG system. I don't want to get too deep into the mechanics of how jobs are scheduled or executed but when the SMG Control Center web application looks up its own hostname, that hostname needs to resolve to one or both of the SMG Control Center's IP addresses.

Thank you,

James Martini

[Jim Wallis]

Hi James,
I am going to open a ticket, not for this issue which may well be solved, but for the more critical issue I have.

I did write a longer follow up but it failed to post for some reason, in short I added an entry to resolve the hostname to the inbound IP yesterday and after reboot the only entry in the log was for an email alert (possibly to tell me the SMG had rebooted) which has failed, and significantly the error had changed from a timeout (in previous errors of the same type) to connection refused on <my hostname>:25.
I just added the outgoing IP and rebooted again and get the same error.

Since the critical problem I have is that my internal mail server is no longer able to connect to SMG on the outbound IP on port 25 (connection refused, meaning no-one in the organisation can send email, and this now seems to be a problem for alert notifications, and I have had no response to my separate thread on it, I will open a ticket for that.

I will also change my backup schedule so I can see if a scheduled backup will work (I normally only do them once per month) to report here, because I can see others are still having problems with that.

[alexander-smg]

Why can’t your peeps send mail thru the smg??

[Jim Wallis]

Do you mean

• why outbound SMTP connections are being refused by SMG (I don't know, I'm trying to find out) or
• can I work around the issue and have users send mail directly to SMG by authenticating to it  (I have, but I prefer LAN users to send via the mail server since messages between colleagues don't need to be filtered - it probably makes no difference to performance for an organisation our size)

[alexander-smg]

Yes that issue. Isn’t the exchange server on the outbound allow list on the smg?

[alexander-smg]

This happened after upgrade? Exchange?

[Jim Wallis]

We don't use exchange, our mail server is a debian VM running Postfix for SMTP and Cyrus for IMAP. And yes it is on the outbound allow list. Also on the allow list is a multifinction device that does scan to email and has very limited options for SMTP setup, and some other hardware that sends email alerts (that probably don't need to go external to the LAN now I think about it).

Debian did have a point release update last week and that has been a consideration.

We have occasionally been having outgoing mail deferred (but eventually sent) since SMG update at the end of Nov. Initially I thought it was related to DDS errors which started at the same time, but checking this week I noticed that the times don't match up, and then realised that in fact postfix does the LDAP lookup to decide if the message can be sent, SMG should simply be accepting it and filtering for spam and viruses.

An email I sent on Tuesday was not received by my client, I re-sent several times and none of them were received (this was when I noticed that the DDS errors were not at the same time as deferrals). But email sent last week since Debian updated had been successful, so the complete stoppage does not tie up exactly with the Debian update. It also doesn't completely tie up with the patch installation for SMG because I found that whilst looking for a solution to the outgoing mail issue, and recognising that I also had the symptoms for that, I decided to go ahead and install it.

The problem mght be in Debain, but all Postfix gets from SMG is "connection refused" and I can't find out why SMG is refusing the connection to determine which system is actually at fault. BUT, note that since applying the IP fix for the SMG scheduled task issue, SMG now gets a connection refused message from itself, so my money is on SMG....

As for the DDS errors (timeouts) obviouly the AD DC has been updated too, but not last week, it actually didn't want an update when all the other windows servers did, and I actually rolled back the updates since the DDS problems started to no effect. This is most likely to do with the number of brute force login attempts (for each of which SMG performs an LDAP lookup to see if it is for a valid user) and spam to invalid addresses, but may also be suggesting that the VM for the DC is under provisioned. This is probably not an SMG issue, but could be.

[alexander-smg]

Are you authenticating from postfix to the smg for outbound email? If so, stop that and try again.

[Jim Wallis]

Hi James,
I don't see a need to open a support ticket until I have determined if the documented fixes have fixed anything, and because our system has relatively light use, it can take a whle to determine that.
Yesterday due to the time zone difference I went ahead and added .11 to the hosts section and rebooted, now that I see your reply I will add .12 and reboot again.

Adding .11 has changed the messages in brightmaillog.log.
Before adding hostname entry:

Jan 12 2023 09:57:27 [BrightmailScheduler_Worker-1] [MailSend] ERROR - javax.mail.MessagingException: Exception reading response;
nested exception is:
java.net.SocketException: Connection reset
Jan 12 2023 09:57:27 [BrightmailScheduler_Worker-1] [AlertNotificationManager] ERROR - com.symantec.smg.controlcenter.BrightmailException: Unable to send an alert notification message about the operation performed on the component. Please check the SMTP Host and Port on the Control Center Settings page.
Jan 12 2023 09:57:27 [BrightmailScheduler_Worker-1] [StatusTask] ERROR - Status poller error. Cannot retrieve status information.: Unable to send an alert notification message about the operation performed on the component. Please check the SMTP Host and Port on the Control Center Settings page.​

 
And after adding the hostname entry:

Jan 12 2023 10:48:46 [https-jsse-nio-443-exec-10] [RebootAction] WARN - Rebooting 1 NOW... 
Jan 12 2023 11:03:04 [BrightmailScheduler_Worker-33] [MailSend] ERROR - javax.mail.MessagingException: Could not connect to SMTP host: leny.selman-marine.com, port: 25;
  nested exception is:
	java.net.ConnectException: Connection refused (Connection refused) 
Jan 12 2023 11:03:04 [BrightmailScheduler_Worker-33] [AlertNotificationManager] ERROR - com.symantec.smg.controlcenter.BrightmailException: Unable to send an alert notification message about the operation performed on the component. Please check the SMTP Host and Port on the Control Center Settings page. 
Jan 12 2023 11:03:04 [BrightmailScheduler_Worker-33] [StatusTask] ERROR - Status poller error. Cannot retrieve status information.: Unable to send an alert notification message about the operation performed on the component. Please check the SMTP Host and Port on the Control Center Settings page. 
​

Obviously the scheduled task in this case is an alert rather than a backup and the issue is with connecting to itself to send mail, well I had only given it the inbound IP to resolve so maybe that shouldn't be a surprise. I have just now added a line to resolve the hostname to .12 (outbound) and I'm awaiting a reboot,  However, the error given has changed from a timeout, to connection refused, which is as much info as I can get from the much more serious problem I am already having with mail from our mail server outbound through the SMG on xxx.xxx.xxx.12:25.
The SMTP port is set to 25 on both IPs, and incoming mail from the internet has so far not been affected as far as I can tell.

That last entry, almost 24 hours ago now, was the last entry in the log before I rebooted after adding .12 so it could be some time before I can confirm whether the problem is solved or not, probably after the weekend.

I will need to open a support ticket for the outbound connection refused issue which is a thread you haven't responded to, but is actually the problem that is crippling our email flow at present...

Thanks

[Jim Wallis]

After further investigation I may have resolved this, details in my other thread:
https://community.broadcom.com/symantecenterprise/discussion/outgoing-connection-refused

I won't determine until tomorrow if it has solved the failing scheduled tasks, I hope so, and I hope the rest of you guys manage to get your problems resolved.

[alexander-smg]

I still get them. Oh no

[James Martini]

Hello Alex,

If you are still getting alerts from the cron daemon and have applied patch 10.8.0-293 then you are likely getting a different alert than the telemetry upload job. Patch 10.8.0-293 addresses the alert from the telemetry upload job as that occurs with every run of the script. If, however, a different cron job is generating alerts, that is likely due to an error which will need to be investigated.

To be clear, SMG 10.8.0 no longer suppresses alert messages from the cron daemon but patch 10.8.0-293 addressed one specific alert that affected all customers and that did not indicate an error condition. 

If you don't already have a support case opened for the continued alerts following application of patch 10.8.0-293, please open one at your earliest convenience.

--
James Martini

[alexander-smg]

Kick butt

[Gokhan DURYILMAZ]

Hello, version 10.8.1-7 has been released. I haven't upgraded yet. Does the new version fix the problem? has anyone tried it?

[alexander smg]

I still get conduit errors

[James Martini]

> I still get conduit errors

Hello Alex. Errors from the conduit process are different from the cron alert emails that we're discussing in this thread. The email alerts from the cron daemon arose in SMG 10.8.0 due to changes in how we process output from cron jobs. Alerts specifically from the telemetry cron job was addressed in SMG patch 10.8.0-293 and in 10.8.1.

The conduit is a different process entirely. If you are seeing errors in the conduit logs, please open a support case so that they can be reviewed and addressed.

[alexander smg]

Lots of issues in 10.8.1 for sure

[James Martini]

Yes. SMG 10.8.1 includes the fix for the telemetry cron job emails from patch 10.8.0-293.