HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Syslog problem
Operating System - HP-UX
1833784
Members
4207
Online
110063
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-07-2003 06:57 AM
03-07-2003 06:57 AM
Syslog problem
Hi
I have a HPUX 11.11 with MC/Service Guard installed. I hav webMethods Apps server running in the same server on a shared disk. We hav the same shared disk that store the webMethods broker.alert and broker.info log file. The MC/Service Guard controls the start/stop of the webMethods and also mount/dismount the shared drive. webMethods uses syslogd to send its logs to broker.alert and broker.info files.
Our /etc/syslog.conf hav an entry for webMethods to writes log to the shared disk directly so all webMethod related logs will redirect to that disk i.e broker.alert and broker.info files.
The syslogd is restarted and verified to be running.
When we do failover test on the webMethods by killing the webMethods process, the MC/Service Guard detected its and starts the failover process which brings down the webMethods process and dismount the shared disk. This causes all session that are using the shared disk to be killed including the syslogd daemon when it dismount.
How to avoid the syslogd daemon from being killed when MC/Service Guard dismount the shared disk?
We can't use local disk to do it because we need to have all the webMethods content from the primary servers when the MC/Service Guard restart the webMethods on secondary servers.
We tried soft-links but it does not solve the problems, because syslogd daemon seems to send webMethods log to syslog.log file instead when syslogd daemon can't find the shared disk. Sometimes nothing got written at all on the log files.
We need to hav the webMethods log in their respective log files(broker.alert, broker.info) instead of syslog.log; and webmethods log files must be stored in the shared disk; and syslogd daemon must not be killed.
I have a HPUX 11.11 with MC/Service Guard installed. I hav webMethods Apps server running in the same server on a shared disk. We hav the same shared disk that store the webMethods broker.alert and broker.info log file. The MC/Service Guard controls the start/stop of the webMethods and also mount/dismount the shared drive. webMethods uses syslogd to send its logs to broker.alert and broker.info files.
Our /etc/syslog.conf hav an entry for webMethods to writes log to the shared disk directly so all webMethod related logs will redirect to that disk i.e broker.alert and broker.info files.
The syslogd is restarted and verified to be running.
When we do failover test on the webMethods by killing the webMethods process, the MC/Service Guard detected its and starts the failover process which brings down the webMethods process and dismount the shared disk. This causes all session that are using the shared disk to be killed including the syslogd daemon when it dismount.
How to avoid the syslogd daemon from being killed when MC/Service Guard dismount the shared disk?
We can't use local disk to do it because we need to have all the webMethods content from the primary servers when the MC/Service Guard restart the webMethods on secondary servers.
We tried soft-links but it does not solve the problems, because syslogd daemon seems to send webMethods log to syslog.log file instead when syslogd daemon can't find the shared disk. Sometimes nothing got written at all on the log files.
We need to hav the webMethods log in their respective log files(broker.alert, broker.info) instead of syslog.log; and webmethods log files must be stored in the shared disk; and syslogd daemon must not be killed.
tyl
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-07-2003 07:08 AM
03-07-2003 07:08 AM
Re: Syslog problem
Isn't it the /etc/inetd.conf where you can set a daemon to respawn ??
I can't find it in the man pages. It means that when inetd finds out syslogd is not running anymore it will be respawned immediatly.
Another solution might be to build in something wihtin your start/stop scripts. Start would do something like "rsh server2 /sbin/init.d/syslog start"
Stop would do a stop and a start, but I don't know if the stop method will definitly work.
Regs David
I can't find it in the man pages. It means that when inetd finds out syslogd is not running anymore it will be respawned immediatly.
Another solution might be to build in something wihtin your start/stop scripts. Start would do something like "rsh server2 /sbin/init.d/syslog start"
Stop would do a stop and a start, but I don't know if the stop method will definitly work.
Regs David
@yourservice
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-07-2003 10:14 AM
03-07-2003 10:14 AM
Re: Syslog problem
I think you ought to verify your system for corruption with either of the following:
check_patches
-or-
swverify -x check_permissions=true \*
For both, review the swverify.log and swagent.log after completion. Both will take several minutes to run.
check_patches
-or-
swverify -x check_permissions=true \*
For both, review the swverify.log and swagent.log after completion. Both will take several minutes to run.
Support Fatherhood - Stop Family Law
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-09-2003 04:22 PM
03-09-2003 04:22 PM
Re: Syslog problem
If I understand correctly, before MC/SG can unmount the file system, it must first terminate all processes with open files on that file system.
If so, to prevent syslogd from being terminated, it must be instructed to close the broker logs before the file system is unmounted. This can only be done with a change in syslog.conf.
If this whole procedure is scripted, then I propose maintaining two similar syslog.conf files, one with the broker logs and the other without, use a symlink to toggle between them, and send a SIGHUP to syslogd after toggling.
I suppose it would be best to have syslog.conf linked to syslog.conf.nobroker at all times so at bootup it doesn't open those logs.
However, modify the webMethods startup script to do the following before webMethods itself is started:
ln -fs /etc/syslog.conf.broker /etc/syslog.conf
kill -HUP $(cat /var/run/syslog.pid)
Then after webMethods is started, do only this:
ln -fs /etc/syslog.conf.nobroker /etc/syslog.conf
Then all MC/SG needs to do before it unmounts the filesystem during failover is this:
kill -HUP $(cat /var/run/syslog.pid)
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP