Question on /var/spool
Last week or maybe the week before someone wiped out our 200 pack. With the help of some friends on this and other boards I have put it MOSTLY back together. It boots and things work so now I'm putting some non critical(or what I'd call non critical) files back where they belong. This morning I was using tar to create a tarball of /spool so I can lay it back into /var/spool. When I went to tar it(-czf) it came back with: tar -czf xspoolo.tgz * tar: postfix/private/rewrite: socket ignored tar: postfix/private/bounce: socket ignored tar: postfix/private/defer: socket ignored tar: postfix/private/trace: socket ignored tar: postfix/private/verify: socket ignored tar: postfix/private/proxymap: socket ignored tar: postfix/private/smtp: socket ignored tar: postfix/private/relay: socket ignored tar: postfix/private/error: socket ignored tar: postfix/private/local: socket ignored tar: postfix/private/virtual: socket ignored tar: postfix/private/lmtp: socket ignored tar: postfix/private/anvil: socket ignored tar: postfix/private/maildrop: socket ignored tar: postfix/private/cyrus: socket ignored tar: postfix/private/uucp: socket ignored tar: postfix/private/ifmail: socket ignored tar: postfix/private/bsmtp: socket ignored tar: postfix/private/vscan: socket ignored tar: postfix/private/procmail: socket ignored tar: postfix/public/cleanup: socket ignored tar: postfix/public/flush: socket ignored tar: postfix/public/showq: socket ignored What the heck is it telling me?? thanks Mace - Ring'em or ping'em. Make PC-to-phone calls as low as 1¢/min with Yahoo! Messenger with Voice. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question on /var/spool
tar won't back up these files, but they will be re-created when those services are startup up again. On Tuesday 23 May 2006 8:53 am, LJ Mace wrote: Last week or maybe the week before someone wiped out our 200 pack. With the help of some friends on this and other boards I have put it MOSTLY back together. It boots and things work so now I'm putting some non critical(or what I'd call non critical) files back where they belong. This morning I was using tar to create a tarball of /spool so I can lay it back into /var/spool. When I went to tar it(-czf) it came back with: tar -czf xspoolo.tgz * tar: postfix/private/rewrite: socket ignored tar: postfix/private/bounce: socket ignored tar: postfix/private/defer: socket ignored tar: postfix/private/trace: socket ignored tar: postfix/private/verify: socket ignored tar: postfix/private/proxymap: socket ignored tar: postfix/private/smtp: socket ignored tar: postfix/private/relay: socket ignored tar: postfix/private/error: socket ignored tar: postfix/private/local: socket ignored tar: postfix/private/virtual: socket ignored tar: postfix/private/lmtp: socket ignored tar: postfix/private/anvil: socket ignored tar: postfix/private/maildrop: socket ignored tar: postfix/private/cyrus: socket ignored tar: postfix/private/uucp: socket ignored tar: postfix/private/ifmail: socket ignored tar: postfix/private/bsmtp: socket ignored tar: postfix/private/vscan: socket ignored tar: postfix/private/procmail: socket ignored tar: postfix/public/cleanup: socket ignored tar: postfix/public/flush: socket ignored tar: postfix/public/showq: socket ignored What the heck is it telling me?? thanks Mace - Ring'em or ping'em. Make PC-to-phone calls as low as 1¢/min with Yahoo! Messenger with Voice. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- Rich Smrcina VM Assist, Inc. Main: (262)392-2026 Cell: (414)491-6001 Ans Service: (360)715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question on /var/spool
Last week or maybe the week before someone wiped out our 200 pack. With the help of some friends on this and other boards I have put it MOSTLY back together. It boots and things work so now I'm putting some non critical(or what I'd call non critical) files back where they belong. This morning I was using tar to create a tarball of /spool so I can lay it back into /var/spool. When I went to tar it(-czf) it came back with: [snip] What the heck is it telling me?? It's telling you that the Unix-domain sockets (ie, named pipes) that postfix uses to communicate with various pieces of itself are special files that tar doesn't know how to handle (or restore), and thus it's skipping them and telling you that it did so. Postfix should recreate them when it starts back up, AFAIK, so in this case, don't worry about it. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question on /var/spool
tar is telling you that it's ignoring the Unix-domain sockets in postfix/private. The sockets are created by the application (postfix) when it starts, so there's no point in adding them to the tarball. -Tim -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of LJ Mace Sent: Tuesday, May 23, 2006 9:53 AM To: LINUX-390@VM.MARIST.EDU Subject: Question on /var/spool Last week or maybe the week before someone wiped out our 200 pack. With the help of some friends on this and other boards I have put it MOSTLY back together. It boots and things work so now I'm putting some non critical(or what I'd call non critical) files back where they belong. This morning I was using tar to create a tarball of /spool so I can lay it back into /var/spool. When I went to tar it(-czf) it came back with: tar -czf xspoolo.tgz * tar: postfix/private/rewrite: socket ignored tar: postfix/private/bounce: socket ignored tar: postfix/private/defer: socket ignored tar: postfix/private/trace: socket ignored tar: postfix/private/verify: socket ignored tar: postfix/private/proxymap: socket ignored tar: postfix/private/smtp: socket ignored tar: postfix/private/relay: socket ignored tar: postfix/private/error: socket ignored tar: postfix/private/local: socket ignored tar: postfix/private/virtual: socket ignored tar: postfix/private/lmtp: socket ignored tar: postfix/private/anvil: socket ignored tar: postfix/private/maildrop: socket ignored tar: postfix/private/cyrus: socket ignored tar: postfix/private/uucp: socket ignored tar: postfix/private/ifmail: socket ignored tar: postfix/private/bsmtp: socket ignored tar: postfix/private/vscan: socket ignored tar: postfix/private/procmail: socket ignored tar: postfix/public/cleanup: socket ignored tar: postfix/public/flush: socket ignored tar: postfix/public/showq: socket ignored What the heck is it telling me?? thanks Mace - Ring'em or ping'em. Make PC-to-phone calls as low as 1¢/min with Yahoo! Messenger with Voice. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Question about sysctl.conf
So, way back when we made a decision to turn on the timer patch for all of our SuSE SLES9 images running on z/VM 5.1. Recently, I noticed (after all this time) that the /etc/sysctl.conf file does not get read at boot time and therefore, we've been running with the timer patch off. This now generates a few questions... 1) If the timer patch has been off for all of this time, is it worth turning on now? We haven't had any significant performance issues to date so how much difference would it really make now? In looking at the average CPU for 2 test images (1 with the patch on, 1 with it off) over the course of a day or so, the one with the timer patch on ran at an average of 0.17% CPU while doing nothing, and the one with the timer patch off ran at an average of 0.19% CPU. I could see this possibly mattering with hundreds of images, but we're somewhere between 30-40. 2) If we decide to turn the patch on, how do you get it to stay on across an IPL. I've included kernel.hz_timer=0 in the sysctl.conf, but it doesn't appear to be read after boot. What are other people doing with this? 3) Are there any particular instances where you wouldn't turn the patch on? E.g. a time server or maybe a mail server??? I don't know... Only test servers??? Etc... Mark Wiggins University of Connecticut Operating Systems Programmer 860-486-2792 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question about sysctl.conf
What makes you think sysctl.conf isn't being read at boot time? It should be. I don't have a SLES system in front of me, but on Red Hat, the /etc/rc.sysinit script applies the settings in sysctl.conf to the running kernel. SLES probably has a similar init script. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Wiggins, Mark Sent: Tuesday, May 23, 2006 11:00 AM To: LINUX-390@VM.MARIST.EDU Subject: Question about sysctl.conf So, way back when we made a decision to turn on the timer patch for all of our SuSE SLES9 images running on z/VM 5.1. Recently, I noticed (after all this time) that the /etc/sysctl.conf file does not get read at boot time and therefore, we've been running with the timer patch off. This now generates a few questions... 1) If the timer patch has been off for all of this time, is it worth turning on now? We haven't had any significant performance issues to date so how much difference would it really make now? In looking at the average CPU for 2 test images (1 with the patch on, 1 with it off) over the course of a day or so, the one with the timer patch on ran at an average of 0.17% CPU while doing nothing, and the one with the timer patch off ran at an average of 0.19% CPU. I could see this possibly mattering with hundreds of images, but we're somewhere between 30-40. 2) If we decide to turn the patch on, how do you get it to stay on across an IPL. I've included kernel.hz_timer=0 in the sysctl.conf, but it doesn't appear to be read after boot. What are other people doing with this? 3) Are there any particular instances where you wouldn't turn the patch on? E.g. a time server or maybe a mail server??? I don't know... Only test servers??? Etc... Mark Wiggins University of Connecticut Operating Systems Programmer 860-486-2792 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question about sysctl.conf
Regarding #2. What is the status of boot.sysctl? linux:/ # chkconfig boot.sysctl boot.sysctl off I believe it needs to be on. Regards, Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Wiggins, Mark Sent: Tuesday, May 23, 2006 8:00 AM To: LINUX-390@VM.MARIST.EDU Subject: Question about sysctl.conf So, way back when we made a decision to turn on the timer patch for all of our SuSE SLES9 images running on z/VM 5.1. Recently, I noticed (after all this time) that the /etc/sysctl.conf file does not get read at boot time and therefore, we've been running with the timer patch off. This now generates a few questions... 1) If the timer patch has been off for all of this time, is it worth turning on now? We haven't had any significant performance issues to date so how much difference would it really make now? In looking at the average CPU for 2 test images (1 with the patch on, 1 with it off) over the course of a day or so, the one with the timer patch on ran at an average of 0.17% CPU while doing nothing, and the one with the timer patch off ran at an average of 0.19% CPU. I could see this possibly mattering with hundreds of images, but we're somewhere between 30-40. 2) If we decide to turn the patch on, how do you get it to stay on across an IPL. I've included kernel.hz_timer=0 in the sysctl.conf, but it doesn't appear to be read after boot. What are other people doing with this? 3) Are there any particular instances where you wouldn't turn the patch on? E.g. a time server or maybe a mail server??? I don't know... Only test servers??? Etc... Mark Wiggins University of Connecticut Operating Systems Programmer 860-486-2792 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question about sysctl.conf
The reason that I don't think that it gets read is because if I do a sysctl -a, kernel.hz_timer=1, although I have it kernel.hz_timer=0 in my /etc/sysctl.conf file. If I issue sysctl -p the setting is changed to what I have in my /etc/sysctl.conf file. There is a boot.sysctl script in /etc/init.d/ that looks like it would do the trick, but when I issue a chkconfig -a boot.sysctl nothing happens. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Meanor, Tim Sent: Tuesday, May 23, 2006 11:14 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Question about sysctl.conf What makes you think sysctl.conf isn't being read at boot time? It should be. I don't have a SLES system in front of me, but on Red Hat, the /etc/rc.sysinit script applies the settings in sysctl.conf to the running kernel. SLES probably has a similar init script. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Wiggins, Mark Sent: Tuesday, May 23, 2006 11:00 AM To: LINUX-390@VM.MARIST.EDU Subject: Question about sysctl.conf So, way back when we made a decision to turn on the timer patch for all of our SuSE SLES9 images running on z/VM 5.1. Recently, I noticed (after all this time) that the /etc/sysctl.conf file does not get read at boot time and therefore, we've been running with the timer patch off. This now generates a few questions... =20 1) If the timer patch has been off for all of this time, is it worth turning on now? We haven't had any significant performance issues to date so how much difference would it really make now? In looking at the average CPU for 2 test images (1 with the patch on, 1 with it off) over the course of a day or so, the one with the timer patch on ran at an average of 0.17% CPU while doing nothing, and the one with the timer patch off ran at an average of 0.19% CPU. I could see this possibly mattering with hundreds of images, but we're somewhere between 30-40.=20 =20 2) If we decide to turn the patch on, how do you get it to stay on across an IPL. I've included kernel.hz_timer=3D0 in the sysctl.conf, = but it doesn't appear to be read after boot. What are other people doing with this? =20 3) Are there any particular instances where you wouldn't turn the patch on? E.g. a time server or maybe a mail server??? I don't know... Only test servers??? Etc... =20 Mark Wiggins University of Connecticut Operating Systems Programmer 860-486-2792 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question about sysctl.conf
Bring up YaST2 - System - Runlevel EditorClick on expert mode. Scroll down to boot.sysctl and ensure that the 'B' box is checked. Meanor, Tim [EMAIL PROTECTED] 05/23/06 9:13 AM What makes you think sysctl.conf isn't being read at boot time? It should be. I don't have a SLES system in front of me, but on Red Hat, the /etc/rc.sysinit script applies the settings in sysctl.conf to the running kernel. SLES probably has a similar init script. - Original Message- From: Linux on 390 Port [mailto:LINUX- [EMAIL PROTECTED] On Behalf Of Wiggins, Mark Sent: Tuesday, May 23, 2006 11:00 AM To: LINUX- [EMAIL PROTECTED] Subject: Question about sysctl.conf So, way back when we made a decision to turn on the timer patch for all of our SuSE SLES9 images running on z/VM 5.1. Recently, I noticed (after all this time) that the /etc/sysctl.conf file does not get read at boot time and therefore, we've been running with the timer patch off. This now generates a few questions... 1) If the timer patch has been off for all of this time, is it worth turning on now? We haven't had any significant performance issues to date so how much difference would it really make now? In looking at the average CPU for 2 test images (1 with the patch on, 1 with it off) over the course of a day or so, the one with the timer patch on ran at an average of 0.17% CPU while doing nothing, and the one with the timer patch off ran at an average of 0.19% CPU. I could see this possibly mattering with hundreds of images, but we're somewhere between 30- 40. 2) If we decide to turn the patch on, how do you get it to stay on across an IPL. I've included kernel.hz_timer=0 in the sysctl.conf, but it doesn't appear to be read after boot. What are other people doing with this? 3) Are there any particular instances where you wouldn't turn the patch on? E.g. a time server or maybe a mail server??? I don't know... Only test servers??? Etc... Mark Wiggins University of Connecticut Operating Systems Programmer 860- 486- 2792 -- For LINUX- 390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX- 390 or visit http://www.marist.edu/htbin/wlvindex?LINUX- 390 -- For LINUX- 390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX- 390 or visit http://www.marist.edu/htbin/wlvindex?LINUX- 390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question on /var/spool
I thought this was the answer but I had to ask for my own piece of mind..or what's left. The resason I asked was when I had copied some other files that had sockets in them I didn't get the msg,but when I asked I was told the sockets would remake themselves when the services (re)started. The hate msgs just confused me, not that confusing me is hard to do. thanks to all Mace Rich Smrcina [EMAIL PROTECTED] wrote: tar won't back up these files, but they will be re-created when those services are startup up again. On Tuesday 23 May 2006 8:53 am, LJ Mace wrote: Last week or maybe the week before someone wiped out our 200 pack. With the help of some friends on this and other boards I have put it MOSTLY back together. It boots and things work so now I'm putting some non critical(or what I'd call non critical) files back where they belong. This morning I was using tar to create a tarball of /spool so I can lay it back into /var/spool. When I went to tar it(-czf) it came back with: tar -czf xspoolo.tgz * tar: postfix/private/rewrite: socket ignored tar: postfix/private/bounce: socket ignored tar: postfix/private/defer: socket ignored tar: postfix/private/trace: socket ignored tar: postfix/private/verify: socket ignored tar: postfix/private/proxymap: socket ignored tar: postfix/private/smtp: socket ignored tar: postfix/private/relay: socket ignored tar: postfix/private/error: socket ignored tar: postfix/private/local: socket ignored tar: postfix/private/virtual: socket ignored tar: postfix/private/lmtp: socket ignored tar: postfix/private/anvil: socket ignored tar: postfix/private/maildrop: socket ignored tar: postfix/private/cyrus: socket ignored tar: postfix/private/uucp: socket ignored tar: postfix/private/ifmail: socket ignored tar: postfix/private/bsmtp: socket ignored tar: postfix/private/vscan: socket ignored tar: postfix/private/procmail: socket ignored tar: postfix/public/cleanup: socket ignored tar: postfix/public/flush: socket ignored tar: postfix/public/showq: socket ignored What the heck is it telling me?? thanks Mace - Ring'em or ping'em. Make PC-to-phone calls as low as 1¢/min with Yahoo! Messenger with Voice. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- Rich Smrcina VM Assist, Inc. Main: (262)392-2026 Cell: (414)491-6001 Ans Service: (360)715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 - New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question about sysctl.conf
Ya, unfortunately I guess, that's what I've got. boot.sysctl No B -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Dell Harris Sent: Tuesday, May 23, 2006 11:22 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Question about sysctl.conf Bring up YaST2 - System - Runlevel EditorClick on expert mode. Scroll down to boot.sysctl and ensure that the 'B' box is checked. Meanor, Tim [EMAIL PROTECTED] 05/23/06 9:13 AM What makes you think sysctl.conf isn't being read at boot time? It should be. I don't have a SLES system in front of me, but on Red Hat, the /etc/rc.sysinit script applies the settings in sysctl.conf to the running kernel. SLES probably has a similar init script. - Original Message- From: Linux on 390 Port [mailto:LINUX- [EMAIL PROTECTED] On Behalf Of Wiggins, Mark Sent: Tuesday, May 23, 2006 11:00 AM To: LINUX- [EMAIL PROTECTED] Subject: Question about sysctl.conf So, way back when we made a decision to turn on the timer patch for all of our SuSE SLES9 images running on z/VM 5.1. Recently, I noticed (after all this time) that the /etc/sysctl.conf file does not get read at boot time and therefore, we've been running with the timer patch off. This now generates a few questions... 1) If the timer patch has been off for all of this time, is it worth turning on now? We haven't had any significant performance issues to date so how much difference would it really make now? In looking at the average CPU for 2 test images (1 with the patch on, 1 with it off) over the course of a day or so, the one with the timer patch on ran at an average of 0.17% CPU while doing nothing, and the one with the timer patch off ran at an average of 0.19% CPU. I could see this possibly mattering with hundreds of images, but we're somewhere between 30- 40. 2) If we decide to turn the patch on, how do you get it to stay on across an IPL. I've included kernel.hz_timer=0 in the sysctl.conf, but it doesn't appear to be read after boot. What are other people doing with this? 3) Are there any particular instances where you wouldn't turn the patch on? E.g. a time server or maybe a mail server??? I don't know... Only test servers??? Etc... Mark Wiggins University of Connecticut Operating Systems Programmer 860- 486- 2792 -- For LINUX- 390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX- 390 or visit http://www.marist.edu/htbin/wlvindex?LINUX- 390 -- For LINUX- 390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX- 390 or visit http://www.marist.edu/htbin/wlvindex?LINUX- 390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question about sysctl.conf
Issue chkconfig boot.sysctl on or consider using /etc/init.d/boot.local instead. Regards, Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Wiggins, Mark Sent: Tuesday, May 23, 2006 8:41 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Question about sysctl.conf Ya, unfortunately I guess, that's what I've got. boot.sysctl No B -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Dell Harris Sent: Tuesday, May 23, 2006 11:22 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Question about sysctl.conf Bring up YaST2 - System - Runlevel EditorClick on expert mode. Scroll down to boot.sysctl and ensure that the 'B' box is checked. Meanor, Tim [EMAIL PROTECTED] 05/23/06 9:13 AM What makes you think sysctl.conf isn't being read at boot time? It should be. I don't have a SLES system in front of me, but on Red Hat, the /etc/rc.sysinit script applies the settings in sysctl.conf to the running kernel. SLES probably has a similar init script. - Original Message- From: Linux on 390 Port [mailto:LINUX- [EMAIL PROTECTED] On Behalf Of Wiggins, Mark Sent: Tuesday, May 23, 2006 11:00 AM To: LINUX- [EMAIL PROTECTED] Subject: Question about sysctl.conf So, way back when we made a decision to turn on the timer patch for all of our SuSE SLES9 images running on z/VM 5.1. Recently, I noticed (after all this time) that the /etc/sysctl.conf file does not get read at boot time and therefore, we've been running with the timer patch off. This now generates a few questions... 1) If the timer patch has been off for all of this time, is it worth turning on now? We haven't had any significant performance issues to date so how much difference would it really make now? In looking at the average CPU for 2 test images (1 with the patch on, 1 with it off) over the course of a day or so, the one with the timer patch on ran at an average of 0.17% CPU while doing nothing, and the one with the timer patch off ran at an average of 0.19% CPU. I could see this possibly mattering with hundreds of images, but we're somewhere between 30- 40. 2) If we decide to turn the patch on, how do you get it to stay on across an IPL. I've included kernel.hz_timer=0 in the sysctl.conf, but it doesn't appear to be read after boot. What are other people doing with this? 3) Are there any particular instances where you wouldn't turn the patch on? E.g. a time server or maybe a mail server??? I don't know... Only test servers??? Etc... Mark Wiggins University of Connecticut Operating Systems Programmer 860- 486- 2792 -- For LINUX- 390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX- 390 or visit http://www.marist.edu/htbin/wlvindex?LINUX- 390 -- For LINUX- 390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX- 390 or visit http://www.marist.edu/htbin/wlvindex?LINUX- 390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question about sysctl.conf
It may be the syntax in the sysctl.conf fileEnsure that there are spaces between the target the '=' and the value kernel.hz_timer = 0 and not kernel.hz_timer=0. Wiggins, Mark [EMAIL PROTECTED] 05/23/06 9:41 AM Ya, unfortunately I guess, that's what I've got. boot.sysctl No B - Original Message- From: Linux on 390 Port [mailto:LINUX- [EMAIL PROTECTED] On Behalf Of Dell Harris Sent: Tuesday, May 23, 2006 11:22 AM To: LINUX- [EMAIL PROTECTED] Subject: Re: Question about sysctl.conf Bring up YaST2 - System - Runlevel EditorClick on expert mode. Scroll down to boot.sysctl and ensure that the 'B' box is checked. Meanor, Tim [EMAIL PROTECTED] 05/23/06 9:13 AM What makes you think sysctl.conf isn't being read at boot time? It should be. I don't have a SLES system in front of me, but on Red Hat, the /etc/rc.sysinit script applies the settings in sysctl.conf to the running kernel. SLES probably has a similar init script. - Original Message- From: Linux on 390 Port [mailto:LINUX- [EMAIL PROTECTED] On Behalf Of Wiggins, Mark Sent: Tuesday, May 23, 2006 11:00 AM To: LINUX- [EMAIL PROTECTED] Subject: Question about sysctl.conf So, way back when we made a decision to turn on the timer patch for all of our SuSE SLES9 images running on z/VM 5.1. Recently, I noticed (after all this time) that the /etc/sysctl.conf file does not get read at boot time and therefore, we've been running with the timer patch off. This now generates a few questions... 1) If the timer patch has been off for all of this time, is it worth turning on now? We haven't had any significant performance issues to date so how much difference would it really make now? In looking at the average CPU for 2 test images (1 with the patch on, 1 with it off) over the course of a day or so, the one with the timer patch on ran at an average of 0.17% CPU while doing nothing, and the one with the timer patch off ran at an average of 0.19% CPU. I could see this possibly mattering with hundreds of images, but we're somewhere between 30- 40. 2) If we decide to turn the patch on, how do you get it to stay on across an IPL. I've included kernel.hz_timer=0 in the sysctl.conf, but it doesn't appear to be read after boot. What are other people doing with this? 3) Are there any particular instances where you wouldn't turn the patch on? E.g. a time server or maybe a mail server??? I don't know... Only test servers??? Etc... Mark Wiggins University of Connecticut Operating Systems Programmer 860- 486- 2792 -- For LINUX- 390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX- 390 or visit http://www.marist.edu/htbin/wlvindex?LINUX- 390 -- For LINUX- 390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX- 390 or visit http://www.marist.edu/htbin/wlvindex?LINUX- 390 -- For LINUX- 390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX- 390 or visit http://www.marist.edu/htbin/wlvindex?LINUX- 390 -- For LINUX- 390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX- 390 or visit http://www.marist.edu/htbin/wlvindex?LINUX- 390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question about sysctl.conf
I just took a look at /etc/sysctl.conf on one of my systems, and there is a mixture of lines with spaces around the equals sign, and no spaces. All the values are in effect, so I don't think this matters. At least not today. That could change some time in the future, of course. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Dell Harris Sent: Tuesday, May 23, 2006 12:00 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Question about sysctl.conf It may be the syntax in the sysctl.conf fileEnsure that there are spaces between the target the '=' and the value kernel.hz_timer = 0 and not kernel.hz_timer=0. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question about sysctl.conf
On 5/23/06, Wiggins, Mark [EMAIL PROTECTED] wrote: 1) If the timer patch has been off for all of this time, is it worth turning on now? The point of the hz_timer is to get periods of inactivity long enough that CP can conclude that the server is apparently idle and review the use of real memory of that server. If the timer interrupts keep the server in queue all the time you eventually end up in Q3 even though your CPU usage is minimal. The amount of work that Linux does on each timer tick is minimal, so the reduction in CPU usage may not be that exciting. My server drops from 0.20% to 0.08%, but that really depends on what your idle server has still going on. With hz_timer=0 the only timer interrupts are when a process asks for the wake-up call. There are some applications that schedule a lot of wake-up calls. I know some applications schedule a wake-up every 25mS - that's about as bad as polling with 10mS, and it certainly does not give CP the 300 mS it needs for queue drop. z/VM 5.2 has some new function to review memory usage of an idle server, even when it does not drop from queue. I have not seen any numbers from that yet, so I cannot tell how effective it is. 3) Are there any particular instances where you wouldn't turn the patch on? E.g. a time server or maybe a mail server??? I don't know... Only test servers??? Etc... The previous incarnation of the timer patch was more expensive on a busy server (because the number of timer interrupts ended up being way more than once every 10mS). With the current implementation this is not an issue anymore. If anyone has measured the hz_timer=1 being a performance improvement, I would be interested to see their numbers. I have not seen it yet. Maybe part of this is due to the belief that if it burns more gas it must be faster... Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question about sysctl.conf
Ok, I put the command sysctl -p in my boot.local file and that worked fine. Thanks to everyone for their input. Mark -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Neubert, Kevin (DIS) Sent: Tuesday, May 23, 2006 11:59 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Question about sysctl.conf Issue chkconfig boot.sysctl on or consider using /etc/init.d/boot.local instead. Regards, Kevin -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Wiggins, Mark Sent: Tuesday, May 23, 2006 8:41 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Question about sysctl.conf Ya, unfortunately I guess, that's what I've got. boot.sysctl No B=09 =20 -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Dell Harris Sent: Tuesday, May 23, 2006 11:22 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Question about sysctl.conf Bring up YaST2 - System - Runlevel EditorClick on expert mode. Scroll down to boot.sysctl and ensure that the 'B' box is checked. Meanor, Tim [EMAIL PROTECTED] 05/23/06 9:13 AM What makes you think sysctl.conf isn't being read at boot time? It should be. I don't have a SLES system in front of me, but on Red Hat, the /etc/rc.sysinit script applies the settings in sysctl.conf to the running kernel. SLES probably has a similar init script. - Original Message- From: Linux on 390 Port [mailto:LINUX- [EMAIL PROTECTED] On Behalf Of Wiggins, Mark Sent: Tuesday, May 23, 2006 11:00 AM To: LINUX- [EMAIL PROTECTED] Subject: Question about sysctl.conf So, way back when we made a decision to turn on the timer patch for all of our SuSE SLES9 images running on z/VM 5.1. Recently, I noticed (after all this time) that the /etc/sysctl.conf file does not get read at boot time and therefore, we've been running with the timer patch off. This now generates a few questions... 1) If the timer patch has been off for all of this time, is it worth turning on now? We haven't had any significant performance issues to date so how much difference would it really make now? In looking at the average CPU for 2 test images (1 with the patch on, 1 with it off) over the course of a day or so, the one with the timer patch on ran at an average of 0.17% CPU while doing nothing, and the one with the timer patch off ran at an average of 0.19% CPU. I could see this possibly mattering with hundreds of images, but we're somewhere between 30- 40. 2) If we decide to turn the patch on, how do you get it to stay on across an IPL. I've included kernel.hz_timer=3D0 in the sysctl.conf, but it doesn't appear to be read after boot. What are other people doing with this? 3) Are there any particular instances where you wouldn't turn the patch on? E.g. a time server or maybe a mail server??? I don't know... Only test servers??? Etc... Mark Wiggins University of Connecticut Operating Systems Programmer 860- 486- 2792 -- For LINUX- 390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX- 390 or visit http://www.marist.edu/htbin/wlvindex?LINUX- 390 -- For LINUX- 390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX- 390 or visit http://www.marist.edu/htbin/wlvindex?LINUX- 390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
IBM WebSphere Application Server Community Edition
On to my next question... The IBM WebSphere Application Server Community Edition appears to be a free download, but is it available for s390? It only shows Linux/Intel and Linux/PPC. Mark Wiggins University of Connecticut Operating Systems Programmer 860-486-2792 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: IBM WebSphere Application Server Community Edition
The IBM WebSphere Application Server Community Edition appears to be a free download, but is it available for s390? It only shows Linux/Intel and Linux/PPC. Mark: IBM has no plans to make WAS CE available on Linux on System z. Jim -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Question about sysctl.conf
Anybody know where the default directory for the later versions of MySQL is? It used to be /var/lib/mysql (I think), but I don't know about nowadays. Thanks, Jon -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
MySQL location
Sorry. Forgot to put the correct subject heading the first time . . . Jon Anybody know where the default directory for the later versions of MySQL is? It used to be /var/lib/mysql (I think), but I don't know about nowadays. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Moving from ESS 800 to DS8100
Louis, Yes, you can copy the volumes using DF/DSS physical dumps. You _must_ have your Linux system down if you take that route, however. That's one reason why I suggested the other method. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Henderson.Louis Sent: Monday, May 22, 2006 5:04 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Moving from ESS 800 to DS8100 Thanks for the great information and detailed instructions. You have saved me bogo mips (millions of instances perusing and searching). One further question. I do have a z/OS system to work with and have both DFDSS and FDR as suggested in a subsequent post: I don't know if you have access to a z/OS system, I did. I had to move my Linux DASD to a new DASD box. I was able to take the Linux systems down for a few hours and move the DASD from a z/OS system. I did full volume copies using a software package, but I think the same thing could be done with DFDSS. That being the case I would then start your process after Once the two copies are done. Right? The best part about this is that my current environment is not changed and I can start all over if a mistake is made. Louis E. Henderson SharedServices - Mainframe -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Post, Mark K Sent: Thursday, May 18, 2006 6:14 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Moving from ESS 800 to DS8100 The SLES system will be very easy, the CentOS one a little bit more work because of the way Red Hat uses file system labels and puts those in /etc/fstab. For the sake of illustration, let's assume that your device numbers and names for the SLES system are: 0300/dev/dasda1 mounted on / 0301/dev/dasdb1 mounted on /usr 0610/dev/dasdc1 (new /) 0611/dev/dasdd1 (new /usr) If your partitioning and mounting scheme is more complex, this method saves you even more time and trouble. Just expand the instructions to cover all the partitions/file systems you might have. Do an internal Linux disk to disk copy of the two disks: dd if=/dev/dasda of=/dev/dasdc bs=4M dd if=/dev/dasdb of=/dev/dasdd bs=4M You can make the blocksize larger or smaller. Note that I used the whole device nodename, not the partitions, i.e. dasda versus dasda1. This makes sure the IPL text, partition tables, etc. get copied. Before the next step, you may need to run fdasd on the two new volumes, just to make sure the newly-created partition table gets read: fdasd /dev/dasdc1 w fdasd /dev/dasdd1 w Once the two copies are done, mount them on /mnt, as they would be on the new storage array. mount /dev/dasdc1 /mnt mount /dev/dasdd1 /mnt/usr chroot /mnt This will cd to /mnt, then change the environment so that it now appears to be the root directory, hence the name change root. What you want to do now is edit /etc/zipl.conf so that only the two new volumes are in your dasd list. Save the changes, then re-run zipl. Make sure the messages that come out look right. Then, re-run mkinitrd. Once the new initrd has been created, I would check to make sure that the DASD parameters that get imbedded in it are right: zcat /boot/new.initrd.name /tmp/initrd.nogz mount -o loop /tmp/initrd.nogz /mnt cd /mnt Look at the linuxrc file to see what it's doing. I don't recall if the initrd has a modules.conf/modprobe.conf in /etc (/mnt/etc at the moment) or not. If it does, look in there. If everything looks fine, cd out of /mnt, umount /mnt, and rm /tmp/initrd.nogz. You should be ready for your changeover to the new storage unit. If you IPL and things go horribly wrong, IPL off the old device and try to fix what was wrong. Note that if you have users or anyone else making changes after the initial copy, you'll need to make those same changes to the new volumes. Now, for the CentOS system, the same methodology will be used, except for the file system labels. Once the two disks have been copied, you'll need to change the file system labels on the new disks. Otherwise, when you try to boot either the old system or the new one, you'll get complaints about duplicate labels, and experience a whole lot of pain (trust me on that one). So, for each file system you have on your original disk, do: e2label /dev/dasda1 e2label /dev/dasdb1 Note the label names. Say they are / and /usr respectively. Then change them on the new file systems: e2label /dev/dasdc1 /new e2label /dev/dadsd1 /usrnew Once you mount /dev/dasdc1 and /dev/dasdd1 on /mnt and /mnt/usr, edit /mnt/etc/fstab, and change the entries: LABEL=/ LABEL=/usr To LABEL=/new LABEL/usrnew That should be the only difference between the two OSes. I just sat down and wrote this up, so I haven't had a chance to test its correctness. So, before you try this, read it over and ask questions about anything that doesn't make sense to you. Mark Post -- For LINUX-390
Re: Question on /var/spool
LJ Mace wrote: Last week or maybe the week before someone wiped out our 200 pack. With the help of some friends on this and other boards I have put it MOSTLY back together. It boots and things work so now I'm putting some non critical(or what I'd call non critical) files back where they belong. This morning I was using tar to create a tarball of /spool so I can lay it back into /var/spool. When I went to tar it(-czf) it came back with: tar -czf xspoolo.tgz * tar: postfix/private/rewrite: socket ignored tar: postfix/private/bounce: socket ignored tar: postfix/private/defer: socket ignored tar: postfix/private/trace: socket ignored tar: postfix/private/verify: socket ignored tar: postfix/private/proxymap: socket ignored tar: postfix/private/smtp: socket ignored tar: postfix/private/relay: socket ignored tar: postfix/private/error: socket ignored tar: postfix/private/local: socket ignored tar: postfix/private/virtual: socket ignored tar: postfix/private/lmtp: socket ignored tar: postfix/private/anvil: socket ignored tar: postfix/private/maildrop: socket ignored tar: postfix/private/cyrus: socket ignored tar: postfix/private/uucp: socket ignored tar: postfix/private/ifmail: socket ignored tar: postfix/private/bsmtp: socket ignored tar: postfix/private/vscan: socket ignored tar: postfix/private/procmail: socket ignored tar: postfix/public/cleanup: socket ignored tar: postfix/public/flush: socket ignored tar: postfix/public/showq: socket ignored What the heck is it telling me?? It doesn't back up sockets. Those get created when needed. Note that results of backing up and restoring open files are undefined. If you are dealing in mail when you back up, you may have damaged mail files, and if you restore, you may send duplicate mail. This last also applies if you back up unsent mail. What to do? Your choice. Probably, sending all mail before backup is impractical - some next hop is likely to be down. There may be similar considerations for other software. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: MySQL location
Jon Brock wrote: Sorry. Forgot to put the correct subject heading the first time . . . Jon Anybody know where the default directory for the later versions of MySQL is? It used to be /var/lib/mysql (I think), but I don't know about nowadays. Probablly depends on whether you use a package from RH, SUSE, Debian, and if you get it from MYSQL itself the answer may be different again. _I_ would inspect the package: rpm -qlp mysql* | grep ^/var For Debian, I think you can figure it out at packages.debian.org -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: IBM WebSphere Application Server Community Edition
IBM has no plans to make WAS CE available on Linux on System z. I could see some value in potential hardware sales for IBM if peope would be able to download and try WAS on System z. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
