search for: door_cal

Hi all, I am installing a zone onto two different V445s running S10U4 and the zones are taking hours to install (about 1000 packages), that is, the problem is identical on both systems. A bit of trussing and dtracing has shown that the pkginstalls being run by the zoneadm install are making door_call calls to nscd that are taking very long, so far observed to be 5 to 40 seconds, but always in times divisible by 5 seconds (5, 10, 15, etc.), leading to the thought that it is one or more name service timeouts. Eventually, once the door_calls finish, the actual package install is very quick. Ther...

Is the following a known problem: =============================================================== [2000/01/26 09:41:03, 0] lib/fault.c:fault_report(41) INTERNAL ERROR: Signal 11 in pid 22273 (2.0.6) Please read the file BUGS.txt in the distribution [2000/01/26 09:41:03, 0] lib/fault.c:fault_report(43) =============================================================== This is using the same

...calhost Truss gives this as the last lines: sysinfo(SI_HOSTNAME, "sbl107.mydomain.se", 256) = 14 open64("/var/run/name_service_door", O_RDONLY) Err#2 ENOENT sysinfo(SI_SRPC_DOMAIN, "afa.se", 1024) = 7 door_info(4, 0xFFBC9850) = 0 door_call(4, 0xFFBC9838) = 0 sysinfo(SI_HOSTNAME, "sbl107.mydomain.se", 256) = 14 open64("/var/run/name_service_door", O_RDONLY) Err#2 ENOENT sysinfo(SI_SRPC_DOMAIN, "afa.se", 1024) = 7 door_info(4, 0xFFBC4190) = 0 doo...

...sigaction(SIGCLD, 0xEFFFF360, 0xEFFFF3E0) = 0 627: sigaction(SIGPIPE, 0xEFFFF360, 0xEFFFF3E0) = 0 627: fcntl(8, F_GETFL, 0x00000000) = 2 629: door_info(3, 0xEFFFDEA0) = 0 627: fstat64(8, 0xEFFFF2A8) = 0 629: door_call(3, 0xEFFFDE88) = 0 627: getsockopt(8, 65535, 8192, 0xEFFFF3AC, 0xEFFFF3A4) = 0 629: open("/var/adm/lastlog", O_RDWR|O_CREAT, 0444) = 6 629: llseek(6, 14168, SEEK_SET) = 14168 627: fstat64(8, 0xEFFFF2A8) = 0...

....003 43 19 getrlimit .000 1 memcntl .000 15 sysconfig .000 5 lwp_sigmask .000 2 lwp_private .000 1 llseek .089 13688 door_info .000 14 door_call .086 7130 schedctl .000 1 resolvepath .000 18 getdents64 .000 2 stat64 .000 3 fstat64 .112 20377 zone_getattr .000 1 zone_lookup .000 3...

...uot;.., 1024) = 749 read(256, 0x003F5A90, 1024) = 0 close(256) = 0 open("/etc/group", O_RDONLY) = 256 close(256) = 0 door_info(4, 0xFFBF8490) = 0 door_call(4, 0xFFBF8478) = 0 so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", 1) = 256 setsockopt(256, tcp, TCP_NODELAY, 0xFFBFBB0C, 4, 1) = 0 fcntl(256, F_GETFL, 0xFF357AA8) = 2 fcntl(256, F_SETFL, 0x00000082) = 0 connect(256, 0x003E9B10,...

...= 0 brk(0x0809FE78) = 0 brk(0x080A1E78) = 0 open64("/var/run/name_service_door", O_RDONLY) = 3 fcntl(3, F_SETFD, 0x00000001) = 0 door_info(3, 0xC6E491F0) = 0 door_call(3, 0x080459F8) = 0 door_info(3, 0x080459C0) = 0 door_call(3, 0x080459F8) = 0 fstat64(2, 0x08046E20) = 0 pingwrite(2, " p i n g", 4) = 4 : unknownwrite(2, " : u...

Ok.. While helping someone else out with a Solaris 6 issue.. I'm noticing something is broken on Solaris 7.. I've not verified it on Linux.. That is my next step. But this is what I'm seeing. I installed the latest CVS snapshot (actually from the Developer's tree but no changes have been made since 21th), compiled, and installed.. and now: ssh localhost "ps -ef" does

...= 8128 [8124] 8128: putmsg(9, 0xFFFFFFFF7FFFCCC0, 0xFFFFFFFF7FFFCCB0, 0) = 0 8128: open("/var/run/syslog_door", O_RDONLY) = 10 8128: door_info(10, 0xFFFFFFFF7FFFCBA8) = 0 8128: getpid() = 8128 [8124] 8128: door_call(10, 0xFFFFFFFF7FFFCB78) = 0 8128: close(10) = 0 8128: fstat(9, 0xFFFFFFFF7FFFD880) = 0 8128: close(9) = 0 8128: sigaction(SIGCLD, 0x00000000, 0xFFFFFFFF7FFFE260) = 0 8128: write(...

...9279: 15.5966 sigprocmask(SIG_BLOCK, 0xFFBFF1E0, 0xFFBFF1F0) = 0 19279: 15.5966 sigprocmask(SIG_SETMASK, 0xFFBFF1F0, 0x00000000) = 0 19279: 15.5967 read(6, "A0E9B6C5 \B6 g03 C\tC59E".., 16384) = 400 19279: 15.5969 door_info(3, 0xFFBFE7C8) = 0 19279: 15.5971 door_call(3, 0xFFBFE7B0) = 0 19279: 15.5972 stat64("/var/adm/lastlog", 0xFFBFE6D0) = 0 19279: 15.5974 open64("/var/adm/lastlog", O_RDONLY) = 9 19279: 15.5975 llseek(9, 2800, SEEK_SET) = 2800 19279: 15.5975 read(9, &quot...

Hi, I am profiling some workloads for the voluntary and involuntary context switches. I am interested in finding out the reasons causing these two types of context switches. As far as I understand, involuntary context switch happens on expiration of time slice or when a higher priority process comes in. While the voluntary switch generally happens when a process is waiting for I/O etc. So to

Hi, I was going through the implementation of the fasttrap provider. I found that when displaced execution happens (ie., when the instruction traced is being executed out of the scratch space) if an asynchrnous signal comes we need to defer the delivery. Can somebody explain why this is necessary and how is it implemented? Thanks in advance Saravanan S -------------- next part -------------- An

http://dovecot.org/releases/dovecot-1.0.rc23.tar.gz http://dovecot.org/releases/dovecot-1.0.rc23.tar.gz.sig Documentation is probably the only important thing left before v1.0. * deliver doesn't ever exit with Dovecot's internal exit codes anymore. All its internal exit codes are changed to EX_TEMPFAIL. * mbox: X-Delivery-ID header is now dropped when saving mails. * mbox: If

http://dovecot.org/releases/dovecot-1.0.rc23.tar.gz http://dovecot.org/releases/dovecot-1.0.rc23.tar.gz.sig Documentation is probably the only important thing left before v1.0. * deliver doesn't ever exit with Dovecot's internal exit codes anymore. All its internal exit codes are changed to EX_TEMPFAIL. * mbox: X-Delivery-ID header is now dropped when saving mails. * mbox: If

I have Solaris 10 U7 that is exporting ZFS filesytem. The client is Solaris 9 U7. I can mount the filesytem just fine but I am unable to write to it. showmount -e shows my mount is set for everyone. the dfstab file has option rw set. So what gives? Phillip -- This message posted from opensolaris.org

I''ve recently re-installed an X4500 running Nevada b109 and have been experiencing ZFS lock ups regularly (perhaps once every 2-3 days). The machine is a backup server and receives hourly ZFS snapshots from another thumper - as such, the amount of zfs activity tends to be reasonably high. After about 48 - 72 hours, the file system seems to lock up and I''m unable to do anything

.../lib/zoneinfo/GB", O_RDONLY) = 5 fstat64(5, 0xFFBFDDE8) = 0 read(5, " T Z i f\0\0\0\0\0\0\0\0".., 1323) = 1323 close(5) = 0 putmsg(3, 0xFFBFE0C0, 0xFFBFE0B4, 0) = 0 open("/var/run/syslog_door", O_RDONLY) = 5 door_info(5, 0xFFBFDFF8) = 0 getpid() = 1087 [1086] door_call(5, 0xFFBFDFE0) = 0 close(5) = 0 fstat(3, 0xFFBFEBD8) = 0 close(3) = 0 sigaction(SIGQUIT, 0xFFBFEBA0, 0xFFBFEC20) = 0 sigaction(SIGINT, 0xFFBFEBA0, 0xFFBFEC20) = 0 open64("/var/run/name_service_door", O_RDONLY) Err#2 ENOENT open("/etc/passwd", O_RDONLY) = 3 fstat6...

Now at 36 hours since zdb process start and: PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 827 root 4936M 4931M sleep 59 0 0:50:47 0.2% zdb/209 Idling at 0.2% processor for nearly the past 24 hours... feels very stuck. Thoughts on how to determine where and why? -- This message posted from opensolaris.org