Log DELL SCv3020

Hello,

Could you provide some details such as what was being done?

Were there any changes being made hardware or software?

Were there any configuration changes being made?

Listed is a decode of each message group and what it usually means on SC Series (SCv3020 / SCOS), followed by a short action plan to clear it or prove whether anything is actually wrong.

What the messages mean

1) MC ... MCLdapRequest::ProcessGPBRequest ... could not read header value

These are directory‑authentication (LDAP/LDAPS) log lines coming from the management/controller process (“MC”). They indicate the controller received an LDAP request it could not parse (bad header) or the read timed out, so it releases a lock and drops the request. In practice this shows up when:

• AD/LDAP endpoint is unreachable, slow, or blocked by a firewall.
• LDAPS is enabled but the controller doesn’t trust the certificate (or the cipher/TLS version doesn’t match).
• Directory settings (Bind DN / Base DN / Group filter) are mis‑configured; the controller drops the request when the payload isn’t what it expects.

Seeing several of these in the same second usually means the auth service restarted and immediately retried the directory probe.

2) BSD ... authd: daemon status=0 length=10

authd is the authentication daemon. A burst of status=0 lines at the same timestamp typically means authd is starting/restarting and writing its status banner. If they repeat continuously (minutes/hours), it suggests authd is trying and failing to fully initialize—again, commonly because the configured LDAP endpoint can’t be reached or the TLS handshake fails.

3) [auth_sc:notice] ... SCOS is ready to receive requests

These notice lines are the “good” side of the restart: the SCOS auth/front‑end says it’s up and will take requests. You’re seeing a normal “service came up” notice right beside the warnings.

4) [auth_sc:error] ... async_ws_open: MC group joined successfully (19)

Despite the word “error” in the tag, this is actually logging the controller joining its internal message (multicast) group; it’s commonly informational when the stack restarts. The key part is “joined successfully”.

5) EVENT: SOAPClient::BMCLogTransfer() Failed! and EVENT: The SEL has additional entries, phonehome!

• The controller tried to pull BMC/SEL logs (think iDRAC SEL) via SOAP and the transfer failed. That’s usually a management network reachability/credential issue or a temporary iDRAC refusal while it’s busy.
• “SEL has additional entries, phonehome!” is the array telling you there are new system‑event logs and—if SupportAssist/PhoneHome is enabled—it wants to upload a case bundle. If PhoneHome isn’t configured, you’ll still see the informational “there are new SEL entries” message.

6) Log Synchronization point ...

Both controllers (“Top/Bottom”) synchronized their internal logs at the marked sequence. That’s normal and just records a clean sync point.

Is this a fault?

From the sequence you pasted, it looks like the auth stack restarted at 17:07:59 (multiple MC/LDAP warnings and authd banners) and then reported “SCOS is ready to receive requests” several times—so it recovered. If these bursts are rare (e.g., after a config change or a controller reboot), it’s not a fault. If they repeat regularly, it points to directory or BMC integration being misconfigured/unreachable and causing periodic restarts/retries.

What to check / how to stop the noise

A) Verify Directory (LDAP/LDAPS) settings in Unisphere/DSM

• Directory servers / ports: 389 for LDAP or 636 for LDAPS.
• Bind DN / Base DN / Group filter: make sure they’re valid and not empty.
• DNS & NTP: SC controllers and DCs must agree on time and be resolvable.
• LDAPS certificate trust: if using LDAPS, import a CA chain the controller trusts; mismatched or self‑signed certs trigger “could not read header” / handshake failures.
• Firewall: open bidirectional TCP to the DCs from both controllers.

If you don’t use external directory auth, simply disable the directory provider in DSM to stop the LDAP polls/retries.

B) Check BMC/SEL collection and SupportAssist

• If the array is set to collect iDRAC/BMC logs or to PhoneHome, confirm the iDRAC IP/credentials and that the management network allows the SOAP/HTTPS call from the controllers to the iDRAC(s).
• If you don’t want automatic SEL transfers, disable the feature or remove the unreachable device entries so the controller doesn’t try to pull logs and log a failure.

C) Confirm the behavior is not continuous

Watch the log for 10–15 minutes. If you only see one burst of these messages followed by normal operation, you can treat it as a transient restart. If you see recurring bursts every few minutes/hours,   fix LDAP/LDAPS or BMC reachability as above.