From: Mark B. <mb...@ca...> - 2013-02-06 22:28:52
|
Thank-you for SCST! It's fast and I've had a lot of fun learning how to implement it. Lots of great resources in the mailing lists too. I'm using SCST to serve up iSCSI only. I've managed to have a relatively stable configuration with the only challenges being hardware. My question is regarding the init.d script. When I run update-rc.d scst defaults I get the following warning about the start and stop runlevel arguments not matching the LSB Default-Start values: update-rc.d: warning: scst start runlevel arguments (2 3 4 5) do not match LSB Default-Start values (3 5) update-rc.d: warning: scst stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (0 1 2 4 6) If I change the "Default-Start" and "Default-Stop" values in the script to match the suggestions I get no errors, but I don't fully understand the implications. I also notice that if I don't change the values it seems that scst doesn't load my config file upon boot (which kinda makes sense to me). If I put the suggested values in it does load on boot. Do the run values vary between flavors of Linux? What are the implications of my changes? Also, in the init.d/scst script it makes a "See also:" reference to refspecs.freestandards.org. I found that the actual addres is http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html Thanks, Mark |
From: Sietse v. Z. <si...@wi...> - 2013-02-07 12:58:19
|
First off, the LSB is the Linux Standard Base. It is a project that has as its goal the standardization of the many different Linux distributions. And there are indeed many minor and even some very major deviations between the distros. Debian for instance has the default run level set to 2. Which historically and in LSB is defined as the single user+ network runlevel and 3 is the default (0 is powerdown 6 reboot). Besides this all distros basically use their own init scripts and functions, which the LSB also aims to standardize. Anyway http://en.wikipedia.org/wiki/Linux_Standard_Base will have some more useful info about the LSB project. And now to answer your question. The LSB specifies that services by default should start in runlevels 3 and 5 and stop in runlevel 0 1 2 4 and 6. This, is of course, in no way a requirement, and any developer or user is free to specify the runlevels in which a service should or will run. And even in certain cases the default might not be applicable or the right choice. Think for instance about single user debugging services, you will not want to have started in the default LSB runlevels 3 and 5. So the implication is just the message, that the service does not follow LSB standards, basivcally saying that you should check whether these settings are ok for your system. Your changes will probably have little effect, none if you are running any of the distros running in the default runlevels of 3 or 5 (X-windows system). However if you are running Debian like me, which uses runlevel 2 as its default than your changes will cause scst not te be started as you would expect, since they are now only started in the default LSB runlevels 3 and 5.\ -Sietse ________________________________ From: Mark Buteyn [mb...@ca...] Sent: Wednesday, February 06, 2013 23:00 To: scs...@li... Subject: [Scst-devel] Debian 6.0.6 update-rc.d LSB Thank-you for SCST! It's fast and I've had a lot of fun learning how to implement it. Lots of great resources in the mailing lists too. I'm using SCST to serve up iSCSI only. I've managed to have a relatively stable configuration with the only challenges being hardware. My question is regarding the init.d script. When I run update-rc.d scst defaults I get the following warning about the start and stop runlevel arguments not matching the LSB Default-Start values: update-rc.d: warning: scst start runlevel arguments (2 3 4 5) do not match LSB Default-Start values (3 5) update-rc.d: warning: scst stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (0 1 2 4 6) If I change the "Default-Start" and "Default-Stop" values in the script to match the suggestions I get no errors, but I don't fully understand the implications. I also notice that if I don't change the values it seems that scst doesn't load my config file upon boot (which kinda makes sense to me). If I put the suggested values in it does load on boot. Do the run values vary between flavors of Linux? What are the implications of my changes? Also, in the init.d/scst script it makes a "See also:" reference to refspecs.freestandards.org<http://refspecs.freestandards.org>. I found that the actual addres is http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html Thanks, Mark |
From: Mark B. <mb...@ca...> - 2013-02-07 13:49:41
|
Thanks for that thorough explanation Sietse, that helped. After doing more reading on LSB given the link you provided and Wikipedia, it appears that I found a sore spot between Debian and other distros. I'm fairly confident based on your explanation and the descriptions of runlevels for LSB http://refspecs.linuxbase.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/runlevels.htmland the description for runlevels for Debian http://wiki.debian.org/RunLevel that my changes to make Default-Start to 2 3 4 5 and Default-Stop to 0 1 6 are correct for Debian. By your description I probably only needed to move 2 to the Default-Start to make it work correctly, but I have no reason to not move 4 as well. On Thu, Feb 7, 2013 at 7:57 AM, Sietse van Zanen <si...@wi...> wrote: > First off, the LSB is the Linux Standard Base. It is a project that has as > its goal the standardization of the many different Linux distributions. And > there are indeed many minor and even some very major deviations between the > distros. Debian for instance has the default run level set to 2. Which > historically and in LSB is defined as the single user+ network runlevel and > 3 is the default (0 is powerdown 6 reboot). Besides this all distros > basically use their own init scripts and functions, which the LSB also aims > to standardize. > > > > Anyway http://en.wikipedia.org/wiki/Linux_Standard_Base will have some > more useful info about the LSB project. > > > > And now to answer your question. The LSB specifies that services by > default should start in runlevels 3 and 5 and stop in runlevel 0 1 2 4 and > 6. This, is of course, in no way a requirement, and any developer or user > is free to specify the runlevels in which a service should or will run. > And even in certain cases the default might not be applicable or the right > choice. Think for instance about single user debugging services, you will > not want to have started in the default LSB runlevels 3 and 5. > > > > So the implication is just the message, that the service does not follow > LSB standards, basivcally saying that you should check whether these > settings are ok for your system. Your changes will probably have little > effect, none if you are running any of the distros running in the default > runlevels of 3 or 5 (X-windows system). > > > > However if you are running Debian like me, which uses runlevel 2 as its > default than your changes will cause scst not te be started as you would > expect, since they are now only started in the default LSB runlevels 3 and > 5.\ > > > > -Sietse > > > > ________________________________ > From: Mark Buteyn [mb...@ca...] > Sent: Wednesday, February 06, 2013 23:00 > To: scs...@li... > Subject: [Scst-devel] Debian 6.0.6 update-rc.d LSB > > Thank-you for SCST! It's fast and I've had a lot of fun learning how to > implement it. Lots of great resources in the mailing lists too. > > I'm using SCST to serve up iSCSI only. I've managed to have a relatively > stable configuration with the only challenges being hardware. My question > is regarding the init.d script. When I run > > update-rc.d scst defaults > > I get the following warning about the start and stop runlevel arguments > not matching the LSB Default-Start values: > > update-rc.d: warning: scst start runlevel arguments (2 3 4 5) do not match > LSB Default-Start values (3 5) > update-rc.d: warning: scst stop runlevel arguments (0 1 6) do not match > LSB Default-Stop values (0 1 2 4 6) > > If I change the "Default-Start" and "Default-Stop" values in the script to > match the suggestions I get no errors, but I don't fully understand the > implications. I also notice that if I don't change the values it seems > that scst doesn't load my config file upon boot (which kinda makes sense to > me). If I put the suggested values in it does load on boot. > > Do the run values vary between flavors of Linux? What are the implications > of my changes? > > Also, in the init.d/scst script it makes a "See also:" reference to > refspecs.freestandards.org<http://refspecs.freestandards.org>. I found > that the actual addres is > http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html > > > Thanks, > > Mark > > > -- Mark Buteyn Technology Coordinator Calvin Christian Schools 616.538.0990 |
From: Bart V. A. <bva...@ac...> - 2013-02-07 13:48:46
|
On 02/06/13 23:00, Mark Buteyn wrote: > update-rc.d: warning: scst start runlevel arguments (2 3 4 5) do not > match LSB Default-Start values (3 5) > update-rc.d: warning: scst stop runlevel arguments (0 1 6) do not match > LSB Default-Stop values (0 1 2 4 6) Which version of SCST are you using ? The only supported versions are 2.2.1 and the trunk (3.0-pre). As far as I know both use "# Default-Start: 3 5" in the SCST init script. Bart. |
From: Mark B. <mb...@ca...> - 2013-02-07 13:53:21
|
I pulled version 2.2.x branch from SVN on a fresh install of Debian. I tried with the trunk version on a fresh install, but got kernel panics under moderate write loads. I don't know enough about how to accurately report panics to submit them... On Thu, Feb 7, 2013 at 8:48 AM, Bart Van Assche <bva...@ac...> wrote: > On 02/06/13 23:00, Mark Buteyn wrote: > >> update-rc.d: warning: scst start runlevel arguments (2 3 4 5) do not >> match LSB Default-Start values (3 5) >> update-rc.d: warning: scst stop runlevel arguments (0 1 6) do not match >> LSB Default-Stop values (0 1 2 4 6) >> > > Which version of SCST are you using ? The only supported versions are > 2.2.1 and the trunk (3.0-pre). As far as I know both use "# Default-Start: > 3 5" in the SCST init script. > > Bart. > > -- Mark Buteyn Technology Coordinator Calvin Christian Schools 616.538.0990 |
From: Sietse v. Z. <si...@wi...> - 2013-02-07 15:19:33
|
Yes I have also seen some strange things with debian 6.0.6 with the backport kernel version 3.2.35. I did not get any kernel panics, but even worse. Under heavy load the system just dies slowly without any message or warning (with scst trunk version). Since this system was also heavily suffering from SATA bus resets I thought it was a hardware problem and RMAd the motherboard. I reveived the replacement yesterday so will do more testing this weekend. Relaying this to the list as now it seems I am not the only one having an issue with debian 6.0.6 and trunk scst. -Sietse ________________________________ From: Mark Buteyn [mb...@ca...] Sent: Thursday, February 07, 2013 14:53 To: Bart Van Assche Cc: scs...@li... Subject: Re: [Scst-devel] Debian 6.0.6 update-rc.d LSB I pulled version 2.2.x branch from SVN on a fresh install of Debian. I tried with the trunk version on a fresh install, but got kernel panics under moderate write loads. I don't know enough about how to accurately report panics to submit them... On Thu, Feb 7, 2013 at 8:48 AM, Bart Van Assche <bva...@ac...<mailto:bva...@ac...>> wrote: On 02/06/13 23:00, Mark Buteyn wrote: update-rc.d: warning: scst start runlevel arguments (2 3 4 5) do not match LSB Default-Start values (3 5) update-rc.d: warning: scst stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (0 1 2 4 6) Which version of SCST are you using ? The only supported versions are 2.2.1 and the trunk (3.0-pre). As far as I know both use "# Default-Start: 3 5" in the SCST init script. Bart. -- Mark Buteyn Technology Coordinator Calvin Christian Schools 616.538.0990 |
From: Bart V. A. <bva...@ac...> - 2013-02-07 15:36:39
|
On 02/07/13 16:19, Sietse van Zanen wrote: > Yes I have also seen some strange things with debian 6.0.6 with the > backport kernel version 3.2.35. I did not get any kernel panics, but > even worse. Under heavy load the system just dies slowly without any > message or warning (with scst trunk version). > > Since this system was also heavily suffering from SATA bus resets I > thought it was a hardware problem and RMAd the motherboard. I revived > the replacement yesterday so will do more testing this weekend. > > Relaying this to the list as now it seems I am not the only one having > an issue with debian 6.0.6 and trunk scst. Maintaining a stable kernel like 3.2.35 is a difficult job. It is easy to make a mistake while backporting patches from more recent kernels. The following might help to figure out what's going on: - Compiling the Linux kernel repeatedly is a good test to verify the system memory. This is a more intensive test than e.g. memtest. - Enabling kernel debugging can help to figure out what the cause of the problem is. You can e.g. configure the kernel to use SLUB and boot with slub_debug=FZPU, enable linked list debugging, etc. Bart. |
From: Emmanuel F. <ef...@in...> - 2013-02-07 21:03:34
|
Le Thu, 07 Feb 2013 16:36:30 +0100 vous écriviez: > Maintaining a stable kernel like 3.2.35 is a difficult job. As an aside, I always run a plain vanilla kernel on my servers, home-compiled (currently 3.2.37) and home-configured. It always perform much better than the debian one. Of course configuring a new release is somewhat time-consuming, but well worth the performance gain. -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | <ef...@in...> | +33 1 78 94 84 02 ------------------------------------------------------------------------ |
From: Sietse v. Z. <si...@wi...> - 2013-02-14 13:50:15
|
Over the past week I have done testing with and without debug kernels. So far I have not been able to reproduce the issue. I am beginning to think in my case it really was a hardware error. I have however only tested with a single VMWare ESX host and not with a cluster, I have been able to generate more load than my cluster ever has, but it might still be a LUN reservation problem. I will also be abandoning Debian in favor of a system that I am custom building, so whatever tests and results I post in the future they will no longer apply to debian. Bart, What kernel version would you recommend for using with scst? -Sietse -----Original Message----- From: Bart Van Assche [mailto:bva...@ac...] Sent: Thursday, February 07, 2013 16:37 To: Sietse van Zanen Cc: Mark Buteyn; scs...@li... Subject: Re: [Scst-devel] Debian 6.0.6 update-rc.d LSB On 02/07/13 16:19, Sietse van Zanen wrote: > Yes I have also seen some strange things with debian 6.0.6 with the > backport kernel version 3.2.35. I did not get any kernel panics, but > even worse. Under heavy load the system just dies slowly without any > message or warning (with scst trunk version). > > Since this system was also heavily suffering from SATA bus resets I > thought it was a hardware problem and RMAd the motherboard. I revived > the replacement yesterday so will do more testing this weekend. > > Relaying this to the list as now it seems I am not the only one having > an issue with debian 6.0.6 and trunk scst. Maintaining a stable kernel like 3.2.35 is a difficult job. It is easy to make a mistake while backporting patches from more recent kernels. The following might help to figure out what's going on: - Compiling the Linux kernel repeatedly is a good test to verify the system memory. This is a more intensive test than e.g. memtest. - Enabling kernel debugging can help to figure out what the cause of the problem is. You can e.g. configure the kernel to use SLUB and boot with slub_debug=FZPU, enable linked list debugging, etc. Bart. |
From: Bart V. A. <bva...@ac...> - 2013-02-14 14:25:31
|
On 02/14/13 14:50, Sietse van Zanen wrote: > Bart, > What kernel version would you recommend for using with scst? The safest choice is an enterprise kernel (RHEL, SLES, CentOS, ...). On the systems I use for testing SCST I'm running the latest stable kernel from kernel.org, the kernels maintained by Greg KH. I need these kernels anyway when running performance measurements since these contain the newest features and latest performance improvements. Bart. |