Starting with Solaris 11, OS development and update will follow a continuous delivery model, whih means the next few years will see lots of incremental improvements within 11.x instead of a major release like Solaris 12.
It’s also very good to see that extended support is planned for the next 25 years or so:
Most of you are probably aware with the fact that by default any processes you may have running within your session will be killed once you terminate the session. The most common example is logging onto a remote server via SSH, starting some command and then closing the terminal session.
As you know, this happens because when your’e terminating your shell it ends up sending the SIGHUP signal to all the child processes, notifying them about the end of the session and therefore instructing them to wrap up whatever it was they were doing and to terminate.
I’ve been working with a support engineer on replacing an SC battery in one of T2000 servers recently, and noticed that immediately upon rebooting a server it may not be possible to get battery and fans stats because prtdiag command wouldn’t work (picld daemon not fully operating yet).
Turns out, there’s another way to get this info – simply use #. to get back into ALOM and run the showevnironment command. Among other things, it reports battery status:
Solaris administrators with solid Linux experience are usually installing top on their systems because of convenience. Quite a few administrators are aware of prstat but don't see benefits of using its format which somewhat differs from top. And a really small number of Solaris sysadmins really know how to use the prstat command properly. I consider myself a power user, so won't even be claiming to be a prstat guru, but these command examples will hopefully teach you a thing or two.
Just thought I’ll take a few minutes to welcome you to the new year and to thank you once again for staying with the Solaris Blog for so long!
My plans for this blog are quite humble in the view of Solaris not being a primary Unix-like OS at work anymore, but I’m still quite curious about a few things and would gladly share knowledge and answer your questions to my best ability.
So far, the following topics appear to be most useful:
I had to change the host name in one of Solaris zones today, and just out of curiousity looked into /etc/init.d/network script. That’s how I learned a new (to me) option of the uname command, which seems to be specific to Solaris: uname -S <newhostname>.
So here’s a very simple procedure for updating the hostname of your Solaris 10 server.
Now that some of the systems I have to regularly patch are Solaris 10 ones, I have to get used to the new patch return codes which one can see when applying one of the Sun’s recommended patchsets. It’s similar to the Solaris 8/9 patchset installation codes, but there are more codes added to the list.
Just a few days ago I’ve been busy configuring one of the Solaris 10 zones on a DMZ server, and sure enough I hit one of the most common IP-related issues with non-global zones.
Shared IP configuration for non-global Solaris zones
By default, non-global zones will be configured with a shared IP functionality. What this means is that IP layer configuration and state is shared between the zone you’re creating and the global zone. This usually implies both zones being on the same IP subnet for each given NIC.
It’s been quite a while since I’ve cleared one of internal disks in my Netra t105 to bring it under ZFS control. As a result, I now have a 33Gb zfs-pool to experiment with. Today I had some spare time, so I decided to share with you the very basics of managing ZFS filesystems.
I just couldn’t wait any longer, and decided to try something with ZFS. And what do you know? I’ve found a very useful advice from Ben Rockwood, which allows us use regular files created with mkfile as virtual disks for ZFS. VERY useful, especially when you really want to play with such a great technology and maybe try various configurations, but there are no spare physical disks for such experiments.
Many of you have already heard about Solaris 10 zones – it’s a virtualization technology which allows you to create isolated and secure environments for running applications. For end-users these environments look just like separate abstract machines with Solaris 10 installed on them. Inside each zone, all the processes don’t see anything happening in all the other zones on a system. Isolation is done on such a level that processes of one zone can’t see or affect processes of any other zone.
Today I’ve met a problem which I easily solved with the help of inetadm, and here’s the entry explaining what happened.
When trying to FTP some files off my laptop, I’ve noticed FTP client failing to parse the ls -l output due to Russian weekdays used in listing. It was obvious that such FTP daemon behavior was due to one of its options, which specifically made sure the daemon inherited all the environment variables. Luckily such a behavior was easy to change with inetadm:
Quite often it is more important for you to see the whole picture, rather than to know each case when a particular probe fires. For instance, observing a process which consumes a lot of CPU time according to prstat, we ask ourselves: what is this process doing? And often we think about the overall number of system calls executed by this process, and not every particular one of these system calls.
Macro variables are meant to make your life MUCH easier when scripting with DTrace. Names of such variables must begin with a $ sign, and DTrace will automatically replace all the macro variables with the appropriate values when parsing your script.
Full list of macro variables can be found here, I will only talk about $target variable this time.
$target specifies the PID of the process you associate with your DTrace script.
One of the most useful (for me) options in DTrace is flowindent. All it does is indent the entry to each function with “->”, and mark the return from this function with “<-“. Doesn’t seem like much, does it? But just look at the results!
The following example catches all the probes of the fbt provided. By default (that’s our case since we’re not changing any other options but flowindent), DTrace registers and prints to the standard output all the probes matched in the tracing process.
One more variation of using DTrace allows to track which system calls are made from a certain process. Or do the same for lots of processes, if you use execname and not PIDs… Such a command line will show you all system calls made by Xorg in the last 5 seconds: solaris# dtrace -n 'syscall:::entry [...]
I’m slowly getting used to seeing and using DTrace in my everyday work… For example, here’s a start of the most basic analysis. My setup: The system is constantly busy with something, and our task is to find what’s responsible for this. How? One of the possible solutions is to simply watch the system for [...]
Here are just some of the revolutionary changes introduced in Solaris 10: DTrace – dynamic tracing DTrace allows you to dynamically trace anything and everything in real time. You can observe processes both in userland and kernel space, watch them as closely as you want and this all with virtually no performance impact. This allows [...]
I’ve finally got some spare time to download a PEAR module for DTrace. What a great module! I’ve found a little problem with it, wrote a letter to Wez Furlong, and he immediately changed the source code to make it work even better. Thanks a lot, Wez! So, here it is – my first PHP [...]
Now that we know how to create non-global zones in Solaris, it’s probably time to learn some basics of zones configuration. Most work is done with zonecfg which has been mentioned in my Solaris zones: a working example post. Example of fully configuring a Solaris 10 zone For starters, let’s have a look at the [...]
Finally, I’ve found some time to finish off the on-board network adapters configuration in Solaris 10 for my Asus A8N-SLI motherboard. As I’ve already told before, this motherboard comes equipped with 2 network adapters:nForce4 and Yukon Gigabit Ethernet 10/100/1000Base-T Adapter. Both adapters are based on Marvell chips – they are Marvell 88E8001-LKJ1 (PCI Gigabit Ethernet) [...]