06-04-2014
Sendmail not logging after upgrade to 7.1 TL2 SP3
Has anyone seen an issue where sendmail stops logging any debug messages after upgrading to 7.1 TL2 SP3?
The only APAR I see is for a "priv_raise failed" message in syslog.
Thanks.
7 More Discussions You Might Find Interesting
1. AIX
Hi all,
We are recently migrated to AIX 5.3 ML8 SP3 on pseries systems,when we run the nmon we noted that the nmon display doubled no. of CPU's i.e we have physically 8 CPU's on p570 machine but nmon displays 16. Is this a bug of this version or what?
Thanks in Advance (3 Replies)
Discussion started by: m_raheelahmed
3 Replies
2. Solaris
I'm being forced to upgrade my Sendmail to version 8.14.2. We currently run what comes stock with the Solaris 10 build. I've been working on this for several days getting Sendmail installed and running again. Now it's telling me that I have to install Berkely database. I've never done this... (1 Reply)
Discussion started by: buckhtr77
1 Replies
3. UNIX for Dummies Questions & Answers
hi I have Suse Ent 10 SP3 that when I reboot the server sometimes it won't... it behaves like this
up and running If I rebooted boots ok
so up and running again and If I rebooted again it won't from Hadr Drives
What I can check on my boot/grub?
why sometimes boots OK and sometimes does... (0 Replies)
Discussion started by: karlochacon
0 Replies
4. UNIX for Dummies Questions & Answers
hi guys
I got something I haven't been able to fix
I configure a Linux Suse 10 box, added static IP, DNS (resolv), gateway (routes) but I am not able to ping other servers by name but nslookup works and the server can navigate on internet
check below
the problematic server is server-host20
... (4 Replies)
Discussion started by: kopper
4 Replies
5. Solaris
We have a machine that we upgraded today. After the upgrade, I am getting connection refused on any emails from a remote host that uses an alias. If I send email directly to a user on the upgraded host, from a remote host, that works fine. If I send email to an alias on the ugraded machine, from... (3 Replies)
Discussion started by: brownwrap
3 Replies
6. Linux
When unlocking a Linux server's console there's no event indicating successful logging
Is there a way I can fix this ?
I have the following in my rsyslog.conf
auth.info /var/log/secure
authpriv.info /var/log/secure (1 Reply)
Discussion started by: walterthered
1 Replies
7. Solaris
Hi all,
I have read about sendmail running as 2 separate process.
1 as a MSP, and the other as the real daemon or MTA.
In my current configuration,
the sendmail-client is disabled.
Both submit.cf and sendmail.cf are left as default untouch
I do not specified any mailhost... (3 Replies)
Discussion started by: javanoob
3 Replies
LEARN ABOUT DEBIAN
mail::spamassassin::logger
Mail::SpamAssassin::Logger(3pm) User Contributed Perl Documentation Mail::SpamAssassin::Logger(3pm)
NAME
Mail::SpamAssassin::Logger - SpamAssassin logging module
SYNOPSIS
use Mail::SpamAssassin::Logger;
$SIG{__WARN__} = sub {
log_message("warn", $_[0]);
};
$SIG{__DIE__} = sub {
log_message("error", $_[0]) if $_[0] !~ /in eval/;
};
METHODS
add_facilities(facilities)
Enable debug logging for specific facilities. Each facility is the area of code to debug. Facilities can be specified as a hash
reference (the key names are used), an array reference, an array, or a comma-separated scalar string. Facility names are case-
sensitive.
If "all" is listed, then all debug facilities are implicitly enabled, except for those explicitly disabled. A facility name may be
preceded by a "no" (case-insensitive), which explicitly disables it, overriding the "all". For example: all,norules,noconfig,nodcc.
When facility names are given as an ordered list (array or scalar, not a hash), the last entry applies, e.g. 'nodcc,dcc,dcc,noddc' is
equivalent to 'nodcc'. Note that currently no facility name starts with a "no", it is advised to keep this practice with newly added
facility names to make life easier.
Higher priority informational messages that are suitable for logging in normal circumstances are available with an area of "info".
Some very verbose messages require the facility to be specifically enabled (see "would_log" below).
log_message($level, @message)
Log a message at a specific level. Levels are specified as strings: "warn", "error", "info", and "dbg". The first element of the
message must be prefixed with a facility name followed directly by a colon.
dbg("facility: message")
This is used for all low priority debugging messages.
info("facility: message")
This is used for informational messages indicating a normal, but significant, condition. This should be infrequently called. These
messages are typically logged when SpamAssassin is run as a daemon.
add(method => 'syslog', socket => $socket, facility => $facility)
"socket" is the type the syslog ("unix" or "inet"). "facility" is the syslog facility (typically "mail").
add(method => 'file', filename => $file)
"filename" is the name of the log file.
add(method => 'stderr')
No options are needed for stderr logging, just don't close stderr first.
remove(method)
Remove a logging method. Only the method name needs to be passed as a scalar.
would_log($level, $facility)
Returns 0 if a message at the given level and with the given facility would be logged. Returns 1 if a message at a given level and
facility would be logged normally. Returns 2 if the facility was specifically enabled.
The facility argument is optional.
close_log()
Close all logs.
perl v5.14.2 2011-06-06 Mail::SpamAssassin::Logger(3pm)