Solaris

We have recently installed syslog-ng on at Sun t5240 running Solaris 10.

There seem to be a number of problems connected with the installation the most significant of which is that the messages file is no longer rotating.

The /etc/logadm.conf file has been changed to reflect syslog-ng rather than syslog to no avail.

While attempting to diagnose the problem it was noticed that there are two syslog-ng processes running (only the second of which is in the pid file). Also a kill -HUP on either process seems to have no effect at all.

Has anyone else experienced a problem like this ?

Well, it is not right, but kill or kill -9 is more effective. Catchable signals tend to just ask demons for optional activities, like reconfiguration. Maybe they were started so simultaneously they did not see each other.

That is a possibility but the two processes form part of the same ptree and a kill of whatever type on the second process has no effect what so ever.

A kill -9 on the first process kills both and re-starts the syslog-ng (with two processes again) but even this does not work when used in the logadm.conf file.

Having two syslog-ng processes is the normal way of operation: the first one is the "supervisor", which restarts the second syslog-ng process, if it stops abnormally.
The documentation at the BalaBit website should have more details (can't post URL, as I don't have five posts yet...).
CzP / BalaBit - syslog-ng upstream

So, two processes was a red herring, but what is your test, failure criteria and logging if any?

Just added to the syslog-ng FAQ (sorry, still unable to post links, so I quote it):

= Question =
Is it normal, that I always see two syslog-ng processes runing?
= Answer =
Yes, by default syslog-ng has a supervisor process, which monitors the child. If the child crashes, the supervisor process automatically restarts it. Its behavior is controlled by the command line: '''--process-mode=<foreground|background|safe-background>''' The default is '''safe-background''' which enables the supervisor. The other two disables it.
In practice the child is the main process, the supervisor is only there to restart it in the following cases:
* it was killed by a signal
* it exited with a non-zero return value
When shutting down syslog-ng, the child process needs to receive a TERM signal, which will exit with a zero return value and also brings away the supervisor process.

You would be better off putting syslog-ng under SMF control. Then all you would need to do is use the refresh/restart command.