RE: DO NOT UPGRADE TO POTATO. MENU UPLOAD ON OCT 2 KILLS SYSTEMS
2.1.3-2 is one that does it ... It doesn't totally kill the system .. It seems to start up the various wm's, and they run at about 95% cpu and 88%+ memory for about 2-5 mins (each), but they do die (or finish?) and everything is fine (my worst case, I saw gnome-panel running at 95% for about 3 mins, then wmaker running at that for 3 mins.. (in console mode))... Its an annoyance, but it doesn't kill the system .. (at least on 3 of mine it didn't) Terry > > > "Adam" == Adam Heath <[EMAIL PROTECTED]> writes: > > Adam> I just did an upgrade. The menu pkg ate memory like no > Adam> tomorrow. > [...] > Adam> Cease and desist at all costs. > > Adam> I have just been informed on irc that a fixed menu is in > Adam> incoming. So, it should all be fixed tomorrow. > [...] > > Adam, thanks. What are the menu package versions (broken and fixed)? > Thanks. > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] >
RE: Packages should not Conflict on the basis of duplicate functionality
Looking back on it .. I guess the chkconfig idea wasn't as good as I was originally thinking .. Irix has been the main OS at my company until recently when I started moving the apps over to high end Linux boxes, and have gotten used to the chkconfig setup .. (which serves more purposes than just preventing daemons from starting .. its also used for tracing and debugging .. ie, you can have a trace/debug log created whenever you boot, and also use it to prevent the scripts from display a lot of info (ie, make them quiet) .. I got used to the idea of 'chkconfig trace on' rebooting, and using that to debug startup failures, etc... 'checkconfig autoconfig on' to tell it to use dhcp, etc.. it just made it a bit easier than editing the config scripts and placing exit's in them, and then removing them later .. or removing links, and then recreating, etc...) So, I withdraw my suggestion ;-) -Terry > On Sun, 3 Oct 1999, Terry Katz wrote: > > > Why not implement a system similar to that in Irix ( and a few > other sysv > > style systems ), and use a 'chkconfig' type setup.. > > > > Irix implements it with a config directory (/etc/config), which contains > > files with the same name as the init script or app, and > contains a single > > word .. 'on' or 'off' .. > > > > so, you can issue: > > > > chkconfig postgresql on > > /etc/init.d/postgresql start > > chkconfig postgresql off > > This is possibly a good idea. However, if you're gonna be doing this, why > not just remove the symlink from /etc/rc2.d? When you want the daemon > back recreate the symlink. I'm under the impression that package updates > would recreate this link, so maybe that wouldn't work very well. > > > The modifications to add this to the distribution shouldn't be that > > difficult .. the chkconfig (or whatever you want to call it) > script can be > > used to both test for and set the options.. > > > > chkconfig [ [on/off]] .. leave off the last parameter to > check for the > > status inside an init.d script and start based on that .. > (leave off second > > parameter to see a complete list of whats on/off) > > > > The initial change to add this to the init scripts could take a while > > (although its simple to just add it to the beginning of the > init scripts, > > and just exit if the config is off), but once its implemented > it would be a > > nice tool.. no? (every now and again it would be nice to be able to > > chkconfig gdm off, and/or chkconfig network off, etc...) > > How is "chkconfig network off" any better/easier than "/etc/init.d/network > stop" (aside from the fact it won't get restarted when you reboot)? I > thought that's what different runlevels were for, having different daemons > started when you boot. Maybe I'm just thinking that mucking with > /etc/rcS.d/ as easy enough, but I suppose a chkconfig would be easier for > those less familiar with the init system. > > I don't like the idea of adding this check to each init script. Wouldn't > it be better to add this check to /etc/init.d/rcS when it goes through the > /etc/rcS.d/S??* scripts (since the chkconfig parameter has the same name > as the init script minus the S??)? > > Laters, > > Rick ([EMAIL PROTECTED]) > http://rick.chillin.org > > "As long as you want to live, everywhere will become heaven. > Isn't that right? Because you are still alive. > The chance to achieve happiness, you can find it anywhere." > Yui Ikari > Neon Genesis Evangelion, "The End Of Evangelion" > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] >
RE: Packages should not Conflict on the basis of duplicate functionality
Why not implement a system similar to that in Irix ( and a few other sysv style systems ), and use a 'chkconfig' type setup.. Irix implements it with a config directory (/etc/config), which contains files with the same name as the init script or app, and contains a single word .. 'on' or 'off' .. so, you can issue: chkconfig postgresql on /etc/init.d/postgresql start chkconfig postgresql off The modifications to add this to the distribution shouldn't be that difficult .. the chkconfig (or whatever you want to call it) script can be used to both test for and set the options.. chkconfig [ [on/off]] .. leave off the last parameter to check for the status inside an init.d script and start based on that .. (leave off second parameter to see a complete list of whats on/off) The initial change to add this to the init scripts could take a while (although its simple to just add it to the beginning of the init scripts, and just exit if the config is off), but once its implemented it would be a nice tool.. no? (every now and again it would be nice to be able to chkconfig gdm off, and/or chkconfig network off, etc...) this is a li'l longer implementation (to get started) than changing start->go, and if you change it just locally then whenever a package is upgraded you'll have to add the check line to the beginning of the init scripts .. but long term, this may be a nice feature for debian in general .. no? my 2c -Terry Katz > -Original Message- > From: Craig Sanders [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 02, 1999 6:31 PM > To: Piotr Roszatycki > Cc: Debian Development Mailing List > Subject: Re: Packages should not Conflict on the basis of duplicate > functionality > > > On Sat, Oct 02, 1999 at 04:36:04PM +0200, Piotr Roszatycki wrote: > > > I've install postgresql on my home computer. I need this daemon only > > sometimes. I don't want to start it every time I reboot system. > > you need to do something non-standard, so you should do a little bit of > work to accommodate your own needs. > > if i needed to do the above then i would edit /etc/init.d/postgresql and > (in the case statement) change "start)" to "go)". this way, it would > not get started at boot time, but i could easily start it by running > "/etc/init.d/postgresql go". > > > pros: > > simple. takes <20 seconds with vi. minimal change, so follows principle > of least surprise. easy to remember. init.d scripts are conffiles so it > won't be automatically replaced at the next upgrade. > > cons: > > you have to re-do the change if you ever upgrade and answer "Y" to > dpkg's question about replacing /etc/init.d/postgresql. > > craig > > -- > craig sanders > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] >
