[osol-discuss] svc.startd dumps core and init 6 and shoutdown hangs

2011-04-21 Thread Rswaroop 
hi All,

when i start init 6 or shutdown command the svc.startd hangs and it does not 
reboot. but reboot command works which is not a  grace ful shut down.

Please let me know how to correct this error.

Below are the errors
ptree output
ps -ef|grep init
root 1 0   0   Jan 31 ?  68:57 /sbin/init
root 21028  7155   0 02:40:05 console 0:00 grep init
 ptree 1
1 /sbin/init
  9 /lib/svc/bin/svc.configd
  124   /usr/sbin/ipmon -Ds
  148   /usr/lib/sysevent/syseventd
  163   devfsadmd
  171   /usr/lib/ldoms/drd
  173   /usr/lib/crypto/kcfd
  178   /usr/lib/picl/picld
  209   /usr/lib/inet/in.iked -p 1
  286   /usr/lib/efcode/sparcv9/efdaemon
  303   /usr/sbin/cron
  319   /usr/sbin/rpcbind
  346   /usr/lib/nfs/statd
  387   /usr/lib/nfs/lockd
  389   /usr/lib/saf/sac -t 300
415   /usr/lib/saf/ttymon
  422   /usr/lib/inet/inetd start
193   /opt/openssh/sbin/sshd -i
  204   /bin/ksh /opt/sspfs/rbks/rbackup_start
6386  /usr/sbin/rpc.metad


truss output:

umem allocator: redzone violation: write past end of buffer
buffer=bf6a88  bufctl=bf8708  cache: umem_alloc_24
previous transaction on buffer bf6a88:
thread=7a  time=T-0.27459  slab=be3ec0  cache: umem_alloc_24
libumem.so.1'umem_cache_alloc+0x210
libumem.so.1'umem_alloc+0x60
libumem.so.1'malloc+0x28
librbacmap_r.so'nss_rbacmap_getusernam+0x158
librbacmap_r.so'_nss_rbacmap_getusernam+0x1c
libc.so.1'nss_search+0x20c
libnsl.so.1'_getusernam+0x60
libsecdb.so.1'getusernam+0x2c
libproject.so.1'getdefaultproj+0x70
librestart.so.1'?? (0xff326ac0)
librestart.so.1'restarter_get_method_context+0x614
svc.startd'method_run+0x408
svc.startd'method_thread+0x15c
libc.so.1'?? (0xff1c88ac)
umem: heap corruption detected
stack trace:
libumem.so.1'?? (0xff29c64c)
libumem.so.1'?? (0xff29b468)
librbacmap_r.so'nss_rbacmap_getusernam+0x254
librbacmap_r.so'_nss_rbacmap_getusernam+0x1c
libc.so.1'nss_search+0x20c
libnsl.so.1'_getusernam+0x60
libsecdb.so.1'getusernam+0x2c
libproject.so.1'getdefaultproj+0x70
librestart.so.1'?? (0xff326ac0)
librestart.so.1'restarter_get_method_context+0x614
svc.startd'method_run+0x408
svc.startd'method_thread+0x15c
libc.so.1'?? (0xff1c88ac)
umem allocator: redzone violation: write past end of buffer
buffer=bf2a38  bufctl=bf5770  cache: umem_alloc_24
previous transaction on buffer bf2a38:
thread=79  time=T-0.27129  slab=bedf50  cache: umem_alloc_24
libumem.so.1'umem_cache_alloc+0x210
libumem.so.1'umem_alloc+0x60
libumem.so.1'malloc+0x28
librbacmap_r.so'nss_rbacmap_getusernam+0x158
librbacmap_r.so'_nss_rbacmap_getusernam+0x1c
libc.so.1'nss_search+0x20c
libnsl.so.1'_getusernam+0x60
libsecdb.so.1'getusernam+0x2c
libproject.so.1'getdefaultproj+0x70
librestart.so.1'?? (0xff326ac0)
librestart.so.1'restarter_get_method_context+0x614
svc.startd'method_run+0x408
svc.startd'method_thread+0x15c
libc.so.1'?? (0xff1c88ac)
umem: heap corruption detected
stack trace:
libumem.so.1'?? (0xff29c64c)
libumem.so.1'?? (0xff29b468)


core_dump output
-  lwp# 121 / thread# 121  
 ff1cc5b8 _lwp_kill (6, 0, 20f04, ff29ba3c, ff2ba000, ff2babdc) + 8
 ff299188  (e, f77796e0, 6, 20e40, ff2a6ad8, 0)
 ff29932c  (ff2a7f68, 64, 20d38, ff29ba3c, ff2bd0e8, ff2a7f86)
 ff29c64c  (3b9ac800, 0, 0, bf8708, 78fe, 1)
 ff29b468  (bf6a68, 1, 0, 0, 1ec08, f73d1974)
 f73d26cc nss_rbacmap_getusernam (0, baed08, f777bc60, f7779c60, bf6a68, 
f7779bec) + 254
 f73d28e8 _nss_rbacmap_getusernam (bc5a18, f7779bc8, ff243800, 0, f8dbba00, 
ff3308c8) + 1c
 ff15ea04 nss_search (f73d28cc, ff241a18, ff330480, 2, ff248464, 1) + 20c
 ff02d118 _getusernam (baed08, f777bc60, f7779c60, 2000, f777bc74, ff02ce30) + 
60
 ff252700 getusernam (baed08, f777bd2c, bf2008, 1000, bb, f2ae4) + 2c
 f7661d34 getdefaultproj (baed08, f777bdf0, bf2008, 1000, 80808080, 0) + 70
 ff326ac0 get_projid (bdc008, 57e408, f777bdf0, 0, f8, ff33c000) + d4
 ff327de8 restarter_get_method_context (634, 0, bc5b38, 3fc48, 0, f777bf10) + 
614
 0002df08 method_run (f777bf98, 0, f777bf94, b1d350, , ) + 408


Offline processes
==
online Mar_23   svc:/network/ftp/tcp:default
offlineJan_31   svc:/system/zones:default
offlineJan_31   svc:/system/basicreg:default
offlineJan_31   svc:/application/sthwreg:default
offline*   Mar_23   svc:/milestone/multi-user-server:default
offline*   Mar_23   svc:/application/stosreg:default
maintenanceMar_23   svc:/network/stdiscover:default
maintenanceMar_23   svc:/network/stlisten:default
ls -alrt core*
total 251866
-rw---   1 root root 25762488 Mar 23 01:01 
core.svc.startd.6333.1300842097
-rw---   1 root root 25762488 Mar 23 01:01 
core.svc.startd.6809.1300842103
-rw---   1 root root  52 Mar 23 01:01 
core.upbeat.22717.1300842111
-rw---   1 root root 25770680 Mar 23 02:51 
core.svc.startd.15120.1300848705
-rw---   1 root root 25762488 Mar 23 02:51

[osol-discuss] IPS: package versioning

2011-04-21 Thread M I 
I was able to create an IPS server for our out-of-box driver that allows our 
test engineers to download/install it to their test systems.  One problem I am 
having is that our out-of-box driver version numbers are alpha-numeric.  
Unfortunately IPS only allows strictly numeric version numbers.  E.G. it should 
allow driver version 10.15a.  As it is now, the driver will not post with an 
alpha-numeric version string.

Is this a change that may be forthcoming?
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] IPS: package versioning

2011-04-21 Thread Shawn Walker 

On 04/21/11 11:36 AM, M I wrote:

I was able to create an IPS server for our out-of-box driver that allows our 
test engineers to download/install it to their test systems.  One problem I am 
having is that our out-of-box driver version numbers are alpha-numeric.  
Unfortunately IPS only allows strictly numeric version numbers.  E.G. it should 
allow driver version 10.15a.  As it is now, the driver will not post with an 
alpha-numeric version string.

Is this a change that may be forthcoming?


It's impractical to perform consistent version ordering that works the 
way each package creator expects with non-numeric characters in the 
version.  As such, there are no plans to implement support for 
non-numeric characters in package versions.


Why do you need this support?

-Shawn
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] IPS: package versioning

2011-04-21 Thread M I 
Fair enough, Shawn.  Up until now, our Solaris driver builds had version 
numbers like 1.00a, 1.00b, etc.  but for future builds we will look at changing 
the version numbers to something like 1.00.0, 1.00.1, etc.

We wanted alphanumeric support so that we could continue with the same version 
number scheme that we had been using with previous versions of Solaris - before 
Open Solaris was introduced.  To meet IPS requirements, we will go ahead and 
switch to a fully numeric version scheme.
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] IPS: package versioning

2011-04-21 Thread Shawn Walker 

On 04/21/11 01:05 PM, M I wrote:

Fair enough, Shawn.  Up until now, our Solaris driver builds had version 
numbers like 1.00a, 1.00b, etc.  but for future builds we will look at changing 
the version numbers to something like 1.00.0, 1.00.1, etc.

We wanted alphanumeric support so that we could continue with the same version 
number scheme that we had been using with previous versions of Solaris - before 
Open Solaris was introduced.  To meet IPS requirements, we will go ahead and 
switch to a fully numeric version scheme.


I believe there is intent to add support for a custom version string 
that's used for display purposes only, but otherwise, yes, it's best you 
switch to a numeric versioning system.


-Shawn
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org