To content | To menu | To search
Monday 26 March 2007
By Julien Gabel on Monday 26 March 2007, 16:18
"How to observe stderr of a process" is a recently asked question seen on
the the observability-discuss forum on opensolaris.org, ending
with:
I've tried "truss", but it outputs only part of the buffers being written.
As always, a simple answer show up very quickly from a community member, in this case James Carlson:
Have you tried the "-w" option on truss? "truss -t\!all -w2" should do what you're asking.
Feel good to have lots of nice people on these lists!
Thursday 1 March 2007
By Julien Gabel on Thursday 1 March 2007, 20:03
If so, be patient. In fact it is a high-wanted feature, and
the ZFS team is working hard on it right now. You can learn more about this
feature following the Shrinking a zpool? thread on the zfs-discuss forum on
opensolaris.org. Here are some chosen excerpts.
From Matthew A. Ahrens #1:
Regardless of where you want or don't want to use shrink, we are actively working on this, targeting delivery in s10u5.
From Matthew A. Ahrens #2:
Yeah, the implementation is nontrivial. Of course, this won't have any impact on snapshots, clones, etc. and will happen on-line. Any other solution would be unacceptable.
Howdy... I really like these kind of short and concise answers!
Monday 26 February 2007
By Julien Gabel on Monday 26 February 2007, 19:42
Containers (in fact Zones plus Resource Management features) is a wonderful technology, particularly in virtualized environments. But the fact is that it is not very usable--speaking of the use of RM feature in particular--since it exists many different RM technologies, not always well integrated with Zones capability.
This is why the upcoming work on memory sets and cpu
caps are so interesting, and a more-than-welcome work in order to
enhance and ease the use and deployment of Containers on powerful Solaris
systems.
Enjoy reading Jerry Jelinek's blog entry about this work (already in SXCE build 56!).
Sunday 18 February 2007
By Julien Gabel on Sunday 18 February 2007, 11:14
After live upgrade'ing to snv_57, i was unable to
get network informations, normally obtained using internal DHCP server. In the
system log file, i can see something like:
Sat Feb 17 11:06:18 unic /sbin/dhcpagent[1494]: [ID 91213 daemon.warning] configure_v4_lease: incorrect broadcast address 255.255.255.255 specified for nge0; ignoring Sat Feb 17 11:06:18 unic /sbin/dhcpagent[1494]: [ID 94624 daemon.warning] checkaddr: expected peer address 192.168.1.255 on nge0, have 255.255.255.255
In fact, it seems an old bug was reintroduced while working on an other
(related) CR. See bug report 6516629 for a detail description of the problem. Since it was already
fixed in snv_58, and because there are other known issues with
this build being unable to boot some systems i will stay with build 56, waiting
for build 58.
Monday 22 January 2007
By Julien Gabel on Monday 22 January 2007, 22:35
Although my first bug report against snv_38 on a issue related to the use of a European Type6 USB keyboard with circumflex key seems to be fixed somewhere between snv_39 and snv_54 (at least the status mentioned "Closed: Not Reproducible"), it is not. Filled a new bug report linking to the first one, against snv_55b this time.
Well, i think i will continue to copy and paste the appropriate word using Google searches for a while...
Thursday 11 January 2007
By Julien Gabel on Thursday 11 January 2007, 22:37
I recently learn about NFS on ZFS interaction problem reading the great blog of Ben Rockwood. Although not directly related to what he encountered, this recent great post about how NFS behaves with ZFS backend, particularly on the performance comparison front, says a lot of things about why you might see poor performance using this two technologies together.
To go deeper on this front, you can read more about the ZIL purpose on Eric Kustarz's weblog, and follow closely this ZFS thread on the OpenSolaris website.
Monday 8 January 2007
By Julien Gabel on Monday 8 January 2007, 22:41
As very, very well explained by Stephen Hahn recently, restricting operating system's development specific builds isn't new. In fact, it is more than desirable and as he said on his blog this can serve all of us (community users and community makers):
Certainly current distributions (or emerging ones) might consider using the stabilized build 55--however we got here--as an opportune version to base their next release upon.
Can't wait for the SX:CR build 55 to update my Solaris 11/06 systems!
Monday 4 December 2006
By Julien Gabel on Monday 4 December 2006, 19:36
AS you may notice, there is a new version of the memconf
utility. I am proud that the improved x86 support was done using my Sun Ultra
20 as the reference Opteron (amd64) system ;-)
Here are the outputs before, and after Tom Schmidt's great work (look at the bold informations):
$ memconf -d memconf: V2.0 17-Oct-2006 http://www.4schmidts.com/unix.html hostname: unic.thilelli.net model: Sun Ultra 20 Workstation (Solaris x86 machine) Solaris Nevada snv_51 X86, 32-bit kernel, SunOS 5.11 2 x86 2211MHz cpus diagbanner = Sun Ultra 20 Workstation model = Sun Ultra 20 Workstation modelmore = (Solaris x86 machine) machine = i86pc platform = i86pc perl version: 5.008004 CPU Units: ==== Processor Sockets ==================================== Version Location Tag -------------------------------- -------------------------- AMD Opteron(tm) Processor 148 Socket 939 Memory Units: Type Status Set Device Locator Bank Locator ------- ------ --- ------------------- -------------------- unknown in use 0 A0 Bank0/1 unknown in use 0 A1 Bank2/3 unknown in use 0 A2 Bank4/5 unknown in use 0 A3 Bank6/7 total memory = 2047MB (1.9990234375GB) $ $ memconf -d memconf: V2.1 29-Nov-2006 http://www.4schmidts.com/unix.html hostname: unic model: Sun Ultra 20 Workstation (Solaris x86 machine) Solaris Nevada snv_52 X86, 64-bit kernel, SunOS 5.11 1 AMD Opteron(tm) Processor 148 2211MHz cpu diagbanner = Sun Ultra 20 Workstation model = Sun Ultra 20 Workstation modelmore = (Solaris x86 machine) machine = i86pc platform = i86pc perl version: 5.008004 CPU Units: ==== Processor Sockets ==================================== Version Location Tag -------------------------------- -------------------------- AMD Opteron(tm) Processor 148 Socket 939 Memory Units: Type Status Set Device Locator Bank Locator ------- ------ --- ------------------- -------------------- unknown in use 0 A0 Bank0/1 unknown in use 0 A1 Bank2/3 unknown in use 0 A2 Bank4/5 unknown in use 0 A3 Bank6/7 total memory = 2048MB (2GB)
Thursday 30 November 2006
By Julien Gabel on Thursday 30 November 2006, 22:30
I am really excited by the upcoming Nevada build 53, particularly in the desktop user space. Just read these two posts from Alan Coopersmith and Stephen Hahn to understand why! ;)
Tuesday 14 November 2006
By Julien Gabel on Tuesday 14 November 2006, 22:20
Just a little news to point out some fresh mockup screen shots about the upcoming OpenSolaris and future Solaris installer. All this work came from the Installation and Packaging OpenSolaris community.
Interesting, but i will wait and try an eventual LiveCD/LiveDVD to see it in action, if possible.
« previous entries - page 2 of 3 - next entries »
Multi-platform UNIX systems administrator in mutualized and
virtualized environments
