After installing the Symantec Endpoint Protection (SEP) agent for Linux, it does not honor the assigned LiveUpdate policy.
For example, you install the SEP agent on a client system that does not have access to the Internet. You have assigned a LiveUpdate policy to the client group that the system is a member of. You notice that after installing, definitions are not downloaded by the agent, even after several heartbeat cycles.
Examining the LiveUpdate log (/opt/Symantec/sdcssagent/AMD/sef/Logs/lux.log), you see that the SEP agent tried to connect to Symantec's public LiveUpdate servers and failed. You also note that the agent never tries to download definitions again after the first failed attempt. The agent also never tries to connect to the assigned LiveUpdate source (e.g. a LiveUpdate Administrator server, or a SEPM reverse proxy, etc.), even though the assigned LiveUpdate policy indicates both a valid LiveUpdate source, and a set schedule.
Symantec is investigating this issue. This Knowledge Base article will be updated once the root cause is determined.
To work around this issue, you must restart the Symantec Endpoint Protection (SEP) agent services. This will cause the agent to reload and apply the assigned LiveUpdate policy.
To restart the SEP agent services, issue the following command as a root-level user, depending on which package management system is in use.
RPM-based systems (Red Hat, Oracle, SUSE, etc.): /lib/symantec/start.sh
DEB-based systems (Ubuntu, Debian, etc.): /usr/lib/symantec/start.sh
If the Symantec Endpoint Protection (SEP) agent fails to download content from a LiveUpdate source the first time an attempt is made after the SEP agent services start, no further attempts are made until the agent services are restarted. Editing the assigned LiveUpdate policy on the SEPM, or assigning a new LiveUpdate policy, does not resolve this issue.