When you first install the sensor and configure it to be managed by a CSPM or Unix Director, the packetd process is intentionally not started.
The packetd process is the process that monitors the network and generates alarms.
If the packetd process were started before CSPM is communicating with the sensor, then packetd could generate large amounts of alarms that will sit in queue waiting to be sent to CSPM.
When CSPM connects to the sensor for the first time it could be flooded with alarms that would prevent it from being able to reconfigure the sensor.
So the intial configuration on the sensor prevents packetd from starting up.
This way CSPM can connect to the sensor and an initial configuration can be pushed from CSPM to the sensor. This initial configuration from CSPM will modify the sensor configuration to start up the packetd process, and then you should start seeing alarms in CSPM and the sensor log files.
So since you haven't pushed a configuration from CSPM, the packetd process is not running. Once you successfully push a config from CSPM to the sensor then you shoudl be fine.
Also realize that the log file you are referring to is a memory mapped file. It is created to be a certain size and never groes. Instead when the file is first written it is filled with null bytes and as alarms are written the null bytes are then over written with the actual data from the alarms.
Once the log fills up it is closed and moved to the new directory and a new log is opened.
So you can't use the size of the log file to determine if alarms are being created. You could try "cat log.*" and look at the last entry, and then type "cat log.*" again and see if the last entry changes in order to tell if there are alarms being generated.
