Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked on Solaris x86 machine

2007-12-24 Thread Casper . Dik

Hi All

When I use my 32 bit binary on Solaris x86 machine, I get a segmentation
fault with the following stack trace.

libc.so.1`_malloc_unlocked+0x14c(4000, 3, 80a3130, 1, 8046a38, 805763f)
libc.so.1`malloc+0x39(4000, 0, 8046a1c, fef9e455, fef9158c, 4)
meta_del+0x13(2, 80a3100, 10, 0)
standby_fix+0x75e(2, 8047e8f, 8046b10, 0)
standby+0xcc(2, 8047e8f, 0, 0, 8046bc7)
main+0xd59(6, 8047d80, 8047d9c)
_start+0x80(6, 8047e48, 8047e67, 8047e6a, 8047e7c, 8047e8f)



This stacktrace is symptomatic for memory corruption; because the 32 bit 
and 64 bit allocators round up differently, it is possible that the error 
is masked in 64 bit mode.

Start debugging, e.g., using watchmalloc or libumem or dbx run time access 
checking.

Casper

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


Re: [osol-discuss] SXDE 1/08 features

2007-12-24 Thread Vano Beridze
Alan Coopersmith wrote:
 Girts Zeltins wrote:
   
 Hello,

 Where I can get feature list of SXDE 1/08?
 

 It will be released when SXDE 1/08 is, which is still about
 a month away, though it should mostly be the same set of
 features found in Nevada build 79.

   
 Is there available changelog?
 

 There is no complete changelog for the Solaris Express/Nevada
 series.   You can find changelogs for the ON  X consolidations
 in their community pages on opensolaris.org, and for JDS  SFW
 in their announcements of new builds in the archives of their
 mailing lists on opensolaris.org - while that's only 4 of about
 a dozen consolidations in SXDE, that's probably a bit more than
 half the code base between them.


   
On what gnome is JDS based that will be shipped with SXDE 1/08?
I now use SXDE 9/07 and it's based on Gnome 2.18.x


-- 
Vano Beridze
Software Developer
Silk Road Group


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


Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked on Solaris x86 machine

2007-12-24 Thread Vamsee Priya
Hi 
I don't find a core dump generated when a SIGSEGV is received. I set the
LD_PRELOAD variable to watchmalloc.so.1 but could not find the actual
place of seg. fault as the core dump file is not generated. (I got the
stack trace I pasted when I attached mdb to the process) I don't have a
Sun studio compiler to run dbx.
Any more tools with which I can debug futher?

Thanks
Priya

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of [EMAIL PROTECTED]
Sent: Monday, December 24, 2007 2:27 PM
To: Vamsee Priya
Cc: opensolaris-discuss@opensolaris.org
Subject: Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked on
Solaris x86 machine 


Hi All

When I use my 32 bit binary on Solaris x86 machine, I get a
segmentation
fault with the following stack trace.

libc.so.1`_malloc_unlocked+0x14c(4000, 3, 80a3130, 1, 8046a38, 805763f)
libc.so.1`malloc+0x39(4000, 0, 8046a1c, fef9e455, fef9158c, 4)
meta_del+0x13(2, 80a3100, 10, 0)
standby_fix+0x75e(2, 8047e8f, 8046b10, 0)
standby+0xcc(2, 8047e8f, 0, 0, 8046bc7)
main+0xd59(6, 8047d80, 8047d9c)
_start+0x80(6, 8047e48, 8047e67, 8047e6a, 8047e7c, 8047e8f)



This stacktrace is symptomatic for memory corruption; because the 32 bit

and 64 bit allocators round up differently, it is possible that the
error 
is masked in 64 bit mode.

Start debugging, e.g., using watchmalloc or libumem or dbx run time
access 
checking.

Casper



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


Re: [osol-discuss] system reboot after panic

2007-12-24 Thread Frank . Hofmann

This is:

6367349 Panic on port_remove_event_doneq

which has been fixed in OpenSolaris about 1 1/2 years ago.

Since you're on Solaris 10, any rev released in 2007 has the patch for 
this integrated. 
For more details on S10 patch details or when/how fixed in S10, ask the 
usual support channels ;)

Merry christmas,
FrankH.




On Thu, 20 Dec 2007, Yi Kong wrote:

 Frank is right. I got this:

 # echo ::msgbuf | mdb -k /var/crash/unknown/[uv]*2
 MESSAGE
 PCI-device: [EMAIL PROTECTED], ohci1
 ohci1 is /[EMAIL PROTECTED],60/[EMAIL PROTECTED]
 pcisch0 at root: SAFARI 0x1c 0x60
 pcisch0 is /[EMAIL PROTECTED],60
 NOTICE: ce0: no fault external to device; service available
 NOTICE: ce0: xcvr addr:0x01 - link up 100 Mbps full duplex
 NOTICE: ce1: no fault external to device; service available
 NOTICE: ce1: xcvr addr:0x01 - link up 100 Mbps full duplex
 sd3 at mpt0: target 2 lun 0
 sd3 is /[EMAIL PROTECTED],70/[EMAIL PROTECTED]/[EMAIL PROTECTED],0
 sd4 at mpt0: target 3 lun 0
 sd4 is /[EMAIL PROTECTED],70/[EMAIL PROTECTED]/[EMAIL PROTECTED],0
 dump on /dev/dsk/c1t0d0s1 size 2002 MB
 IP Filter: v4.0.2, running.
 pseudo-device: devinfo0
 devinfo0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: pseudo1
 pseudo1 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: fssnap0
 fssnap0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: ramdisk1024
 ramdisk1024 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: winlock0
 winlock0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: fcode0
 fcode0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: lockstat0
 lockstat0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: vol0
 vol0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: llc10
 llc10 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: tod0
 tod0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: lofi0
 lofi0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd0
 wrsmd0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd1
 wrsmd1 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd2
 wrsmd2 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd3
 wrsmd3 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd4
 wrsmd4 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd5
 wrsmd5 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd6
 wrsmd6 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd7
 wrsmd7 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd8
 wrsmd8 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd9
 wrsmd9 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd10
 wrsmd10 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd11
 wrsmd11 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd12
 wrsmd12 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd13
 wrsmd13 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd14
 wrsmd14 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: wrsmd15
 wrsmd15 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: rsm0
 rsm0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: trapstat0
 trapstat0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: rmcadm0
 rmcadm0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: tsalarm0
 tsalarm0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: dtrace0
 dtrace0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: fbt0
 fbt0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: profile0
 profile0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: systrace0
 systrace0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: sdt0
 sdt0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: fasttrap0
 fasttrap0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: pool0
 pool0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: fcp0
 fcp0 is /pseudo/[EMAIL PROTECTED]
 pseudo-device: fcsm0
 fcsm0 is /pseudo/[EMAIL PROTECTED]
 /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1 (mpt1):
Rev. 7 LSI, Inc. 1030 found.
 /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1 (mpt1):
mpt1 supports power management.
 /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1 (mpt1):
mpt1 Firmware version v1.3.24.0
 /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1 (mpt1):
mpt1: IOC Operational.
 PCI-device: [EMAIL PROTECTED],1, mpt1
 mpt1 is /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1
 /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1/[EMAIL PROTECTED],0 (st10):
HP DAT-72
 st10 at mpt1: target 3 lun 0
 st10 is /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1/[EMAIL PROTECTED],0
 su1 at ebus0: offset 0,2e8
 su1 is /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED],2e8
 PCI-device: [EMAIL PROTECTED], uata0
 uata0 is /[EMAIL PROTECTED],60/[EMAIL PROTECTED]
 sd0 at uata0: target 0 lun 0
 sd0 is /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED],0
 /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1/[EMAIL PROTECTED],0 (st10):
HP DAT-72
 st10 at mpt1: target 3 lun 0
 st10 is /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1/[EMAIL PROTECTED],0

 panic[cpu2]/thread=300075ce980:
 BAD TRAP: type=31 rp=2a100d994c0 addr=0 mmu_fsr=0 occurred in module 
 genunix d
 ue to a NULL pointer dereference


 httpd:
 trap type = 0x31
 pid=29966, pc=0x10f2878, sp=0x2a100d98d61, tstate=0x441607, context=0xd4a
 g1-g7: 

Re: [osol-discuss] SXDE 1/08 features

2007-12-24 Thread Harry Lu

 On what gnome is JDS based that will be shipped with SXDE 1/08?
 I now use SXDE 9/07 and it's based on Gnome 2.18.x


   

It should be GNOME 2.20.x as in nevada 79.

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


Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked on Solaris x86 machine

2007-12-24 Thread Frank . Hofmann
On Mon, 24 Dec 2007, [EMAIL PROTECTED] wrote:


 Hi
 I don't find a core dump generated when a SIGSEGV is received. I set the
 LD_PRELOAD variable to watchmalloc.so.1 but could not find the actual
 place of seg. fault as the core dump file is not generated. (I got the
 stack trace I pasted when I attached mdb to the process) I don't have a
 Sun studio compiler to run dbx.
 Any more tools with which I can debug futher?

 You can use coreadm to redirect the core someplace.

 Does your program call chdir()?  If so, the core dump will be elsewhere.

 Note that with watchmalloc.so.1 you will also need to set some other
 variables.

... which are, like all good Solaris features, documented in the manpages, 
watchmalloc(3MALLOC) in that case :)

watchmalloc and libumem are somewhat complementary, some problems are 
easier to track with one some easier with the other.

Merry christmas,
FrankH.
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org


Re: [osol-discuss] PulseAudio

2007-12-24 Thread Mario Goebbels
 When OSS can support 8-channel, 32 precision, and 192k sampling rate, as 
 well as other feathere,
 what is the specific niftier features that it is lack of compared with ALSA?

A niftier acronym.

(PS: Sarcasm.)

-mg



signature.asc
Description: OpenPGP digital signature
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] PulseAudio

2007-12-24 Thread UNIX admin
 Hi!

Yes, hello.

 Then, Unix Admin asked mumbled

I don't mumble, and what I asked turned out to pertain to the paragraph I'm 
going to quote from you, below. I know why I asked what I asked, and I turned 
out to be correct:

 something about
 whether we might want to install Solaris on my
 machines. Thanks, but no thanks. I already got a good
 operating system, which is called Fedora, and its
 audio system is what I am payed to work on by Red
 Hat.

Typical. Thanks for reinforcing the stereotype.
Be that as it might, luckily for us Solaris users, you have a competition in 
the form of OSS. Now, OSS might not do what you claim, but to put it bluntly, 
it does support what end users need, which is sound.

Or to put it even more bluntly: you don't want to run Solaris, well guess what? 
Shame, but luckily we don't need you either, since you're not the only game in 
town, and don't have the monopoly on providing audio capabilities.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org


Re: [osol-discuss] [ogb-discuss] STAR integration

2007-12-24 Thread Garrett D'Amore
Brian Utterback wrote:
 Joerg Schilling wrote:
   
 The wish resulted in PSARC 2004/480 and I cannot understand why something 
 that
 has been decided to be needed now has no people to work on. It seems that 
 there 
 is a problem in the way Sun is organized if this can happen.
 

 An approved PSARC case has nothing to do with funding/staffing. There 
 are loads of abandoned approved
 PSARC cases in the database. Priorities changes, decisions get made, 
 resources are reallocated. We encourage
 projects to file the PSARC case early in the development process at a 
 time when it is most likely that a
 project might be abandoned. I expect that with OpenSolaris this will 
 become even more common since
 the project work will be entirely at the whim of unpaid volunteers.
   

In other words, Joerg:  You need to file a request-sponsor case if you 
want STAR integrated.  Until you have done that (and nobody here cares 
about what transpired before OpenSolaris take your beef with 
non-open-Solaris up with someone else who cares), please stop 
complaining about it here.  To put it very simply, you are beginning to 
sound like a broken record.

As I said earlier: show your commitment by deeds not words.  The next 
time I hear you complain about how you can't integrate star because Sun 
is against you and no one will do the work, I'm going to add a filter so 
I never see mail from you again, and you'll thereby lose any chance 
whatsoever of getting any help from me in the future.  I would be 
shocked if others haven't already taken such action your incessant 
complaining is driving folks away from what you claim to want most --- 
helping you integrate your software.

-- Garrett

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


[osol-discuss] Crontab -- is cron.d not really a .d directory?

2007-12-24 Thread David Dyer-Bennet
Normally a *.d directory is for package-specific contributions to a 
config file that are all handled together by the configured facility -- 
Linux has logrotate.d for all the log rotating specs from different 
packages, and cron.d for specific cron additions, and so forth.  Emacs 
recognizes an emacs.d directory for some startup file things, too.

Solaris has an /etc/cron.d directory, but the files in it aren't crontab 
files, and the man pages don't make any suggestion of anything except 
user-specific cron files (no system cron file, either, that I can 
find).  So why the heck is the directory called /etc/cron.d?  That's 
just mean; deliberately misleading people!  And misusing the naming 
convention. 

And how much trouble is it to replace the archaic cron system with 
something with decent features?   I suppose that would mess up all the 
package installations?

(truth time: I'm going to be *so* happy when there's a decent ZFS 
implementation in Linux and I can ditch this archaic pile of kludges.)

-- 
David Dyer-Bennet, [EMAIL PROTECTED]; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

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


Re: [osol-discuss] Crontab -- is cron.d not really a .d directory?

2007-12-24 Thread Ignacio Marambio Catán
On Dec 24, 2007 6:44 PM, David Dyer-Bennet [EMAIL PROTECTED] wrote:
 Normally a *.d directory is for package-specific contributions to a
 config file that are all handled together by the configured facility --
 Linux has logrotate.d for all the log rotating specs from different
 packages, and cron.d for specific cron additions, and so forth.  Emacs
 recognizes an emacs.d directory for some startup file things, too.

 Solaris has an /etc/cron.d directory, but the files in it aren't crontab
 files, and the man pages don't make any suggestion of anything except
 user-specific cron files (no system cron file, either, that I can
 find).  So why the heck is the directory called /etc/cron.d?  That's
 just mean; deliberately misleading people!  And misusing the naming
 convention.


from reading crontab's[1] man page you'll see that in /etc/cron.d you
can place the cron.allow/cron.deny files.
you will also see that the user's crontab files are in /var/spool/cron/crontabs.
Linux of course works the same way and stores user's crontab files in
the same place (at least slackware does)
what other cron file are you looking for?

[1]:http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?crontab+1

 (truth time: I'm going to be *so* happy when there's a decent ZFS
 implementation in Linux and I can ditch this archaic pile of kludges.)

solaris is much more than ZFS and the tools are far from archaic

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


Re: [osol-discuss] How to enable XDM?

2007-12-24 Thread Atul Gore
Gary: 

Many Thanks for your help!.

I think there are 2 problems that I have here.

1. cde-login package hasn't been loaded on the operating system.
2. THe Network firewall has been blocking the X display from being sent on LAN. 
 I connected a network cable to  the back of the server i.e. a direct 
connection, and tried to connect to the server, and I was able to see the X 
display, note that this is GDM that I was able to see. (once I made GDM as 
default)

So, in summary, 1/ X display is blocked from the firewall (was/is not able to 
even see xclock over a terminal and passive exceed.) and  am working with the 
network team to get the ports opened for LAN. and 2/ will also get the DVD to 
get cde-login service loaded so that I can get that working too...

Again, can't thank you enough for your help, Gary.

Wish you and everyone the list a very Merry Christmas and a wonderful year  
ahead of 2008!

Best Regards
 - Atul
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org


Re: [osol-discuss] Crontab -- is cron.d not really a .d directory?

2007-12-24 Thread Robin Bowes
David Dyer-Bennet wrote:
 
 (truth time: I'm going to be *so* happy when there's a decent ZFS 
 implementation in Linux and I can ditch this archaic pile of kludges.)
 

David,

I too am from a linux world, moving to Solaris because of zfs.

Sure - things are different, and some of the default configurations and
settings are seemingly old. My take on this is that Solaris tries very
hard to be backwards compatible, so things will work out-of-the box on
current and older versions of the O/S.

The truth is that you need to roll with it more, rather than trying to
 treat Solaris like Linux. Learn how to do what you want/need to do in
the environment you have to work in. There's no point getting annoyed
wityh it - it ain't gonna change any time soon!

R.

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


Re: [osol-discuss] Crontab -- is cron.d not really a .d directory?

2007-12-24 Thread David Dyer-Bennet
Ignacio Marambio Catán wrote:
 On Dec 24, 2007 6:44 PM, David Dyer-Bennet [EMAIL PROTECTED] wrote:
   
 Normally a *.d directory is for package-specific contributions to a
 config file that are all handled together by the configured facility --
 Linux has logrotate.d for all the log rotating specs from different
 packages, and cron.d for specific cron additions, and so forth.  Emacs
 recognizes an emacs.d directory for some startup file things, too.

 Solaris has an /etc/cron.d directory, but the files in it aren't crontab
 files, and the man pages don't make any suggestion of anything except
 user-specific cron files (no system cron file, either, that I can
 find).  So why the heck is the directory called /etc/cron.d?  That's
 just mean; deliberately misleading people!  And misusing the naming
 convention.

 

 from reading crontab's[1] man page you'll see that in /etc/cron.d you
 can place the cron.allow/cron.deny files.
 you will also see that the user's crontab files are in 
 /var/spool/cron/crontabs.
 Linux of course works the same way and stores user's crontab files in
 the same place (at least slackware does)
 what other cron file are you looking for?
   

Where do system cron files go?  The two places they go on Linux and 
other systems I've run don't exist on Solaris. 

Did you understand my point about the normal meaning of thing.d 
directories?  That first paragraph you quoted?

 [1]:http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?crontab+1
   
 (truth time: I'm going to be *so* happy when there's a decent ZFS
 implementation in Linux and I can ditch this archaic pile of kludges.)
 

 solaris is much more than ZFS and the tools are far from archaic
   

I was a Solaris admin before I ever ran a Linux system, but that was 
long enough ago I've lost a lot of what I knew then.  And what Solaris 
does now isn't I'm pretty sure what SunOS did back when I knew it (just 
pre-Solaris if I'm remembering this right).   And what I *really* am is 
a software engineer, so admin stuff was keeping a server working for a 
development group or such, not my primary role.

What happens to me every time I turn around on Solaris these days is 
that tools I'm used to using are missing key features that I use every 
day.  Tar is missing the 'z' option, date is missing all sorts of 
options (can't do conversions on dates specified on the command line), 
touch is missing options I think.  And ps has just totally different 
options, in a different syntax (to get roughly the listing I want every 
time, I need to type ps -ef instead of ps ax I think).  And when I 
try to find anything in the documentation, I mostly can't (or they 
describe three ways of doing things but don't explain why one would 
choose one over another).   And of course there's far, far less 
information on the web that I can find to help me out when I have these 
problems.

And since Linux is what my work laptop and the systems I'm developing 
for at work run, that's what keeps being reinforced; I'm currently 
running Solaris *only* on the file server at home, and I put it there 
only because I wanted ZFS. 

For me, I'd be *immensely* better off running Linux with a good ZFS 
port, if one existed.  I probably also wouldn't have had to wait over a 
year to get all 6 motherboard SATA ports supported, and I *still* 
haven't dared try again to see if the hot-swap I paid so much for is now 
actually supported.

-- 
David Dyer-Bennet, [EMAIL PROTECTED]; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

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


Re: [osol-discuss] Crontab -- is cron.d not really a .d directory?

2007-12-24 Thread Dale Ghent
On Dec 24, 2007, at 4:44 PM, David Dyer-Bennet wrote:

 Solaris has an /etc/cron.d directory, but the files in it aren't  
 crontab
 files, and the man pages don't make any suggestion of anything except
 user-specific cron files (no system cron file, either, that I can
 find).  So why the heck is the directory called /etc/cron.d?  That's
 just mean; deliberately misleading people!  And misusing the naming
 convention.

You're looking for /var/spool/cron for the per-user cron and at job  
storage. This location predates Linux and the existence of vixie cron.  
There isn't a concept as a system-wide crontab in particular, and I'd  
guess the closest approximation of that would be to put the job under  
root's account.

There might be some history context you're missing though. Linux  
distros have historically packaged Vixie cron or a derivative of it.  
Solaris's cron is, well, Solaris's Cron. Two different origins, two  
different histories, and two different ways of doing things.

I bet that since you're coming from a Linux background, you're coming  
to Solaris with a understanding that what's in Linux is what's been  
Universally True since the dawn of *NIX. However, this isn't as Linux  
distros as we know them today have been around for only ~15 years.  
SunOS goes back father than this. For those of us who have used SunOS/ 
Solaris since before Linux, we see the Linux as the perversion here...  
so who is right or wrong is a matter of perspective depending on who  
you ask.

 And how much trouble is it to replace the archaic cron system with
 something with decent features?   I suppose that would mess up all the
 package installations?

Well, here we are in a Open Source world. Never assume never and  
participation is where the rubber meets the road in the purest sense  
of the definition. I'm sure you can find people other than yourself  
who have their own bone to pick with Solaris's cron facility. If you  
truly want to be here in a way that's more than being a Tourist, feel  
free to organize and front your ideas and ask others to join you in  
adding features to cron. Describe a design, find someone (or yourself)  
to provide code diffs and manage the review process for it.  If you  
want to just be a Tourist here, that's perfectly fine too. Just keep  
the vitriol to an absolute minimum and remember that you brought  
yourself to try Solaris in the first place. That's all...


/dale
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org


Re: [osol-discuss] Crontab -- is cron.d not really a .d directory?

2007-12-24 Thread Brian Gupta
In the future, please send these to opensolaris-help, or
sysadmin-discuss. :) Also, check out:
http://www.genunix.org/wiki/index.php/OpenSolaris_New_User_FAQ

On Dec 25, 2007 12:23 AM, David Dyer-Bennet [EMAIL PROTECTED] wrote:
 Ignacio Marambio Catán wrote:
  On Dec 24, 2007 6:44 PM, David Dyer-Bennet [EMAIL PROTECTED] wrote:
 
  Normally a *.d directory is for package-specific contributions to a
  config file that are all handled together by the configured facility --
  Linux has logrotate.d for all the log rotating specs from different
  packages, and cron.d for specific cron additions, and so forth.  Emacs
  recognizes an emacs.d directory for some startup file things, too.
 
  Solaris has an /etc/cron.d directory, but the files in it aren't crontab
  files, and the man pages don't make any suggestion of anything except
  user-specific cron files (no system cron file, either, that I can
  find).  So why the heck is the directory called /etc/cron.d?  That's
  just mean; deliberately misleading people!  And misusing the naming
  convention.
 
 
 
  from reading crontab's[1] man page you'll see that in /etc/cron.d you
  can place the cron.allow/cron.deny files.
  you will also see that the user's crontab files are in 
  /var/spool/cron/crontabs.
  Linux of course works the same way and stores user's crontab files in
  the same place (at least slackware does)
  what other cron file are you looking for?
 

 Where do system cron files go?  The two places they go on Linux and
 other systems I've run don't exist on Solaris.

When you say cron files, I assume you are referring to crontabs?:

All crontabs are in the directory: /var/spool/cron/crontabs/

I think by default the following crontabs exist (This is true for a
Solaris 8 system, I happen to be logged into).:
adm
lp
root
sys
uucp

 Did you understand my point about the normal meaning of thing.d
 directories?  That first paragraph you quoted?

I understand your point, I just don't think it is something to get caught up on.

  [1]:http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?crontab+1
 
  (truth time: I'm going to be *so* happy when there's a decent ZFS
  implementation in Linux and I can ditch this archaic pile of kludges.)
 
 
  solaris is much more than ZFS and the tools are far from archaic
 

 I was a Solaris admin before I ever ran a Linux system, but that was
 long enough ago I've lost a lot of what I knew then.  And what Solaris
 does now isn't I'm pretty sure what SunOS did back when I knew it (just
 pre-Solaris if I'm remembering this right).   And what I *really* am is
 a software engineer, so admin stuff was keeping a server working for a
 development group or such, not my primary role.

 What happens to me every time I turn around on Solaris these days is
 that tools I'm used to using are missing key features that I use every
 day.  Tar is missing the 'z' option, date is missing all sorts of
 options (can't do conversions on dates specified on the command line),
 touch is missing options I think.  And ps has just totally different
 options, in a different syntax (to get roughly the listing I want every
 time, I need to type ps -ef instead of ps ax I think).  And when I
 try to find anything in the documentation, I mostly can't (or they
 describe three ways of doing things but don't explain why one would
 choose one over another).   And of course there's far, far less
 information on the web that I can find to help me out when I have these
 problems.

I know what you are talking about. For tar, I just use gtar, but if
you are used to Linux, that is not intuitive. The Solaris system comes
with two version of ps (the standard and /usr/ucb/ps.) I actually use
both, depending on my needs. The one in /usr/ucb, is the old BSD style
one that takes the -auxwww args. The standard one you use -ef, is
based on ATT System V UNIX. GNU ps, which Linux ships with, accepts
both System V and BSD arguments (to make things more confusing).

 And since Linux is what my work laptop and the systems I'm developing
 for at work run, that's what keeps being reinforced; I'm currently
 running Solaris *only* on the file server at home, and I put it there
 only because I wanted ZFS.

 For me, I'd be *immensely* better off running Linux with a good ZFS
 port, if one existed.  I probably also wouldn't have had to wait over a
 year to get all 6 motherboard SATA ports supported, and I *still*
 haven't dared try again to see if the hot-swap I paid so much for is now
 actually supported.

This is a real problem that Sun is facing. Because they let Linux gain
such popularity, without open sourcing Solaris, a large portion of the
potential userbase is more familiar with the Linux Userland.

A couple of projects are ongoing to address this.

1) Sun is working on a new distro called Indiana, that will attempt to
pick and choose the most appropriate default behaviour, to ease use
for non-Solaris admins.
2) A Debian port of Solaris is well underway. www.gnusolaris.org This
is the 

Re: [osol-discuss] Crontab -- is cron.d not really a .d directory?

2007-12-24 Thread Dale Ghent
On Dec 25, 2007, at 12:23 AM, David Dyer-Bennet wrote:

 What happens to me every time I turn around on Solaris these days is
 that tools I'm used to using are missing key features that I use every
 day.  Tar is missing the 'z' option, date is missing .


snip

 And since Linux is what my work laptop and the systems I'm developing
 for at work run, that's what keeps being reinforced; I'm currently
 running Solaris *only* on the file server at home, and I put it there
 only because I wanted ZFS.


If you're trying to use Solaris and are expecting Linux, then you  
should probably just use Linux and no one should attempt to convince  
you otherwise, as it seems that you've already set up a sort of self- 
fulfilling prophecy for yourself. If Linux offers the homely comforts  
you've come to expect and not wish to compromise on, then that would  
make sense, no?

But here you are, detailing the differences with Solaris that you've  
ran in to. That's fine, everyone does that. But you're doing it in a,  
shall we say, non-constructive manner. Are you just complaining with  
no intention of following up, or are you grousing because you actually  
care and want to improve or at least understand Solaris more? As for  
me, I wouldn't care to write this email if I wasn't interested in  
helping you and others understand what Solaris is and where it comes  
from and where it could go. Accepting that help is up to you though.  
Just let us know.

/dale
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org


Re: [osol-discuss] Crontab -- is cron.d not really a .d directory?

2007-12-24 Thread Shawn Walker
On Dec 24, 2007 11:23 PM, David Dyer-Bennet [EMAIL PROTECTED] wrote:
 Ignacio Marambio Catán wrote:
  On Dec 24, 2007 6:44 PM, David Dyer-Bennet [EMAIL PROTECTED] wrote:
 
  (truth time: I'm going to be *so* happy when there's a decent ZFS
  implementation in Linux and I can ditch this archaic pile of kludges.)
 
 
  solaris is much more than ZFS and the tools are far from archaic
 

 I was a Solaris admin before I ever ran a Linux system, but that was
 long enough ago I've lost a lot of what I knew then.  And what Solaris
 does now isn't I'm pretty sure what SunOS did back when I knew it (just
 pre-Solaris if I'm remembering this right).   And what I *really* am is
 a software engineer, so admin stuff was keeping a server working for a
 development group or such, not my primary role.

 What happens to me every time I turn around on Solaris these days is
 that tools I'm used to using are missing key features that I use every
 day.  Tar is missing the 'z' option, date is missing all sorts of
 options (can't do conversions on dates specified on the command line),

While the Solaris tar program may be missing it, GNU tar is not, and
it is included with Solaris 10:

/usr/sfw/bin/gtar.

If you wanted to use Solaris tar, you can always use gunzip in
combination with tar, etc. The -z option is just a convenience
feature.

As for the date program, I don't use the functionality you're talking
about, so I can't comment on that.

 touch is missing options I think.  And ps has just totally different
 options, in a different syntax (to get roughly the listing I want every
 time, I need to type ps -ef instead of ps ax I think).  And when I

Different operating systems have different software with different
syntax. This should not be surprising.

 try to find anything in the documentation, I mostly can't (or they
 describe three ways of doing things but don't explain why one would
 choose one over another).   And of course there's far, far less
 information on the web that I can find to help me out when I have these
 problems.

Almost all of the problems you're talking about have quite a wealth
of information online.

 For me, I'd be *immensely* better off running Linux with a good ZFS
 port, if one existed.  I probably also wouldn't have had to wait over a
 year to get all 6 motherboard SATA ports supported, and I *still*
 haven't dared try again to see if the hot-swap I paid so much for is now
 actually supported.

GNU/Linux users went through the same pain with certain hardware.

Sometimes Solaris has the upper hand.

For example, Solaris Express worked on my Intel Core 2 Duo system long
before Ubuntu ever did.

Likewise, Windows may have support for certain hardware before Solaris
or GNU/Linux systems.

If you want to see better hardware support; it is only fair you be a
customer of Sun, ask your hardware manufacturer to support Solaris, or
contribute to the efforts to making the support a reality.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

To err is human -- and to blame it on a computer is even more so. -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org


Re: [osol-discuss] Crontab -- is cron.d not really a .d directory?

2007-12-24 Thread David Dyer-Bennet
Dale Ghent wrote:
 On Dec 24, 2007, at 4:44 PM, David Dyer-Bennet wrote:

 Solaris has an /etc/cron.d directory, but the files in it aren't crontab
 files, and the man pages don't make any suggestion of anything except
 user-specific cron files (no system cron file, either, that I can
 find).  So why the heck is the directory called /etc/cron.d?  That's
 just mean; deliberately misleading people!  And misusing the naming
 convention.

 You're looking for /var/spool/cron for the per-user cron and at job 
 storage. This location predates Linux and the existence of vixie cron. 
 There isn't a concept as a system-wide crontab in particular, and I'd 
 guess the closest approximation of that would be to put the job under 
 root's account.

That's the closest I was able to figure out, anyway.  Which really 
complicates system cron entries that don't want to run as root.


 There might be some history context you're missing though. Linux 
 distros have historically packaged Vixie cron or a derivative of it. 
 Solaris's cron is, well, Solaris's Cron. Two different origins, two 
 different histories, and two different ways of doing things.

I even know the name Vixie Cron, yes.

 I bet that since you're coming from a Linux background, you're coming 
 to Solaris with a understanding that what's in Linux is what's been 
 Universally True since the dawn of *NIX. However, this isn't as Linux 
 distros as we know them today have been around for only ~15 years. 
 SunOS goes back father than this. For those of us who have used 
 SunOS/Solaris since before Linux, we see the Linux as the perversion 
 here... so who is right or wrong is a matter of perspective depending 
 on who you ask.

You'd lose.  My first personal contact with Unix was around 1983, at 
DEC-Marlboro, and that was Ultrix-32 on a Vax (I'd been developing 
software professionally for 14 years before that).  Then I had contact 
with SunOS at Network Systems in the 1986 timeframe (in fact I was 
de-facto admin for one server and two workstations hanging off it).  
Then I was news admin at mtn.org and shortly after at gofast.net, on 
SunOS/Solaris boxes (I forget exactly where we were on that line) in the 
early 90s. 

My first Linux box ran kernel 0.99pl13, I believe, but that was after 
I'd had quite a lot of time on Sun and other Unixes.

No, the trouble is that I haven't touched Solaris *since* then, and it's 
changed a lot from what I dimly remember, and in directions different 
from what Linux was doing.  And I develop on and for Linux in my day job 
at the moment, so that's what keeps getting reinforced.

 And how much trouble is it to replace the archaic cron system with
 something with decent features?   I suppose that would mess up all the
 package installations?

 Well, here we are in a Open Source world. Never assume never and 
 participation is where the rubber meets the road in the purest sense 
 of the definition. I'm sure you can find people other than yourself 
 who have their own bone to pick with Solaris's cron facility. If you 
 truly want to be here in a way that's more than being a Tourist, feel 
 free to organize and front your ideas and ask others to join you in 
 adding features to cron. Describe a design, find someone (or yourself) 
 to provide code diffs and manage the review process for it.  If you 
 want to just be a Tourist here, that's perfectly fine too. Just keep 
 the vitriol to an absolute minimum and remember that you brought 
 yourself to try Solaris in the first place. That's all...

First, if I'm heading that direction, I should look at what the other 
distros are packaging; they may very well have more the feel I'm looking 
for.

Also, one thing I'm trying to communicate is that, to an awful lot of 
people coming to Solaris today, it looks and feels archaic.  
Capabilities I'm used to finding are missing from all sorts of tools, in 
particular; that looks like lagging behind the rest of the world.  
Different is a thing that happens, and if one is investigating a 
*different* system, it's expected to some extent.  Better is a good 
thing -- ZFS is better for what I want than the alternatives I know of, 
and I'm putting up with a lot of pain on account of wanting that, in 
addition to learning ZFS itself from scratch.  The svc administration 
system, although I don't understand it thoroughly yet, shows definite 
signs of being significantly *better* than what any Linux distro I've 
worked with has in that area.  The in-kernel CIFS system has the 
possibility of being definitely *better* than SAMBA, though I haven't 
worked with it yet (I've got a samba-based solution in production 
right now at home).  Zones are probably a very useful and powerful 
solution, but I think to a problem I don't have.   It's the cases where 
facilities / capabilities / options are simply *missing*, and sometimes 
I can't find the alternatives easily, that get annoying.   Also the 
severe lagging in hardware support.

Sorry for sharing :-).
-- 

[osol-discuss] Branding error while trying to install informix on solaris

2007-12-24 Thread sameer
I got branding error while trying to install informix on solaris environment.
Can anyone guide me how to fix this error..???
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org