Child pages
  • Phonelogd Service to capture logging from phones
Skip to end of metadata
Go to start of metadata

The 'phonelogd' service is a separate instance of syslogd that is configured to accept remote clients (no filtering) and write everything to .../var/log/sipxpbx/phonelog/phones.log (which is included in snapshots).

The service is not managed by sipXsupervisor (so that it can run when sipXecs is not running) - it is started from init.d as sipxecs is, but it requires a configuration file

.../etc/sipxpbx/phonelog-config with

one configuration item:


(if the file is missing or the value of the above is not 'TRUE', then the service is disabled).

At this point, no default configuration file is installed (in keeping with the new-and-improved philosophy). For now, the configuration file is declared by the sipxconfig-process.xml file so that it can be written using the sipXsupervisor replication mechanisms.

A source build does not activate the phonelogd service, but an rpm install does (but read on).

To enable the service, the configuration file must be written and then the system level service must be (re)started (or, if the service was enabled previously, the system rebooted).

So... the question is - do we really want to also add something to the setup wizard to ask the user whether or not to write that configuration file?


  • No reboot or shell command needed to activate the phone logging.


  • If we write the file in the setup, then sipXconfig has to read it to figure out the state.

I would prefer not to enable this from setup. This is one-time thing, most likely.

Note also - it's not a completely safe thing to allow phones to log this way. It creates an opportunity for an attacker to fill your disk with bogus log entries. Some newer versions of syslogd have some protections against this (but no such protection can be complete or infallible) - unfortunately the CentOS5 syslogd does not. This is good to use in a lab environment or to enable to capture logging from a phone to pore over its messages when and if the need arises, but typically you would leave it "disabled" and not running.

  • No labels