Dr. Martin Mundschenk wrote:
I think we need a bit more information here. You say the system
rebooted but don't say way (the sendmail messages alone are not
indicative of a reboot). Was this a panic?
Where do I get more information? At least there is nothing more in syslog.
System messages are recorded in /var/adm/messages on Solaris (assuming
you've not directed them elsewhere in /etc/syslog.conf). Search them for
the word "panic" or "savecore". Also, find the line which begins "SunOS
Release" and look at the stuff before it. For example, this was a clean
shutdown and reboot:
Nov 20 16:56:39 snv ntpd[618]: [ID 702911 daemon.notice] ntpd exiting on
signal 15
Nov 20 16:56:39 snv /usr/dt/bin/ttsession[949]: [ID 649700 daemon.error]
exiting
Nov 20 16:56:42 snv syslogd: going down on signal 15
Nov 20 16:56:42 snv rpcbind: [ID 564983 daemon.error] rpcbind
terminating on signal.
Nov 20 16:57:07 snv genunix: [ID 672855 kern.notice] syncing file systems...
Nov 20 16:57:07 snv genunix: [ID 904073 kern.notice] done
Nov 23 09:17:13 snv genunix: [ID 540533 kern.notice] ^MSunOS Release
5.11 Version snv_126 64-bit
Nov 23 09:17:13 snv genunix: [ID 943908 kern.notice] Copyright 1983-2009
Sun Microsystems, Inc. All rights reserved.
Nov 23 09:17:13 snv Use is subject to license terms.
Incidentally, looking in /var/log/syslog (which is where I presume you
started) I also see these three lines:
Nov 23 09:17:59 snv sendmail[554]: [ID 702911 mail.warning]
gethostbyaddr(192.168.56.1) failed: 1
Nov 23 09:17:59 snv sendmail[633]: [ID 702911 mail.info] starting daemon
(8.14.3+Sun): queue...@00:15:00
Nov 23 09:17:59 snv sendmail[634]: [ID 702911 mail.info] starting daemon
(8.14.3+Sun): smtp+queue...@00:15:00
So these may be a red herring, and my guesswork above may not be valid :-)
(maybe somebody with sendmail experience can explain to us why this IP
address seems to crop up?)
My guess on the sendmail and groups issue is a name service problem.
Checking sendmail's source, the message prints h_errno returned from
gethostbyaddr which, from <netdb.h> is HOST_NOT_FOUND.
Again, guessing, I would speculate that wherever 192.168.56.1 is
defined is the same place as where the groups are defined, and they
became inaccessible for some reason.
Well, 192.168.56.1 is no address in our home network and I don't know,
why sendmail wants to contact it.
See above. This seems to be something in sendmail itself (or perhaps the
default config).
Where are the missing groups defined?
Only local, I guess in files (PAM?).
/etc/group would be the place to check then. What is the timestamp on
that file? Was it modified around the time your groups stopped working?
Some more esoteric possibilities are a ZFS rollback during the panic
somehow undid your changes (unlikely), or maybe an upgrade had been
completed, the new BE activated, but not yet rebooted. Changes then made
to the /etc/group would not be reflected in the new BE, and the the
panic would cause the system to boot from the new BE, etc...
Let's start with the panic message and the output from "beadm list" to
start with.
Regards,
Brian
What name service are you using?
If NIS/NIS+/LDAP, are all the configured servers/replicas still
running?
Not configured
Did somebody delete these entries from the name service?
Can any other hosts which use the same name service resolve these
entries? e.g. Does "getent hosts 192.168.56.1" return anything?
no
What are the nsswitch.conf entries for hosts: and group: (and
possibly netgroup: if you're using it).
passwd: files
group: files
hosts: files dns
Martin
------------------------------------------------------------------------
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
--
Brian Ruthven
Solaris Revenue Product Engineering
Sun Microsystems UK
Sparc House, Guillemont Park, Camberley, GU17 9QG
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
