RE: [Cooker] About CVS initscripts
> Just to add some fire... How will tmp clean > scripts work? Has anyone cared about this? I > just opened a few tarballs and got 200Mb on > ~/tmp. And tha's 10% of my disk free space. a > few days and I get "partition is full". > Before a script cleaned up the stuff every 24 > hours on /tmp. So I didn't care. Now I have to > think that you have to clean not only /tmp but > also a few /home/*/tmp's. Once again, since I'm a "screen" user, I'm going to mention the fact that "screen" places a kind of lock file (pid.screen_name) file for each screen in ~/tmp. Removing these isn't a good thing. I've been known to have a single screen running for 60-70 days. Maybe we should get "screen" to stick things in /var/lock instead, so it eliminates the problem? > In the meantime I would like to note a > psychological moment - many users have tmp for > storing archives. It is a method coming from > old DOS times where many people used directory > TMP for temporary storage (TEMP was the > swap/drop/trash directory) I always made a download directory back then, and I still do today.. but you're right, I remember a number of people who did it that way. Don Head [[EMAIL PROTECTED]] Linux Mentor, LCP, Network+ [1 314 692-1942] Wave Technologies, Inc. [1 800 826-4640 x1942] [AIM - Don Wave][ICQ - 18804935][Yahoo - Don_Wave]
Re: [Cooker] About CVS initscripts
Just to add some fire... How will tmp clean scripts work? Has anyone cared about this? I just opened a few tarballs and got 200Mb on ~/tmp. And tha's 10% of my disk free space. a few days and I get "partition is full". Before a script cleaned up the stuff every 24 hours on /tmp. So I didn't care. Now I have to think that you have to clean not only /tmp but also a few /home/*/tmp's. In the meantime I would like to note a psychological moment - many users have tmp for storing archives. It is a method coming from old DOS times where many people used directory TMP for temporary storage (TEMP was the swap/drop/trash directory) Ektanoor
RE: [Cooker] About CVS initscripts
>>> As an example I state two of them: How near >>> to SystemV are getting? >>> Isn't /etc/profile.d/tmpdir.* a little bit >>> dangerous for users with homes in NFS/SAMBA >>> or with very narrow quota? Shouldn't be made >>> a "pre-check" before setting TMPDIR? >> >> this is a side i didn't check, you may are >> right but i don't see exactly the problem ? > > The problem is the possbility of fast overloads > of home directory. Temporary files are very > "specific" to their programs. In cases when > programs can't write to their configuration or > temporary files, a set of problems may arise. > Here we have a NFS homedirectory tree (10Mb > quota). When the directories get loaded it is > frequent to meet two conditions: I thought I would mention something I noticed regarding personal tmp/ directories. I use "screen" a lot, at least more than the average user. Each screen places a pid.screenname file in tmp/. If a user has their home directory stored on a central NFS server, and is logged in on multiple machines, the screen command is using the same tmp/ directory for all it's screens, regardless of the system it's running on. This opens the possibility of two screens with the same name and process ID placing a temporary file in the user's tmp/. When running "screen -ls" on a system, any screens running on another system (but in the same tmp/ directory) show up as dead. It's then very easy to "screen -wipe" a process that actually is still running on another machine. Just some food for thought.. Don Head [[EMAIL PROTECTED]] Linux Mentor, LCP, Network+ [1 314 692-1942] Wave Technologies, Inc. [1 800 826-4640 x1942] [AIM - Don Wave][ICQ - 18804935][Yahoo - Don_Wave]
Re: [Cooker] About CVS initscripts
Pedro Rosa schrieb:
>
> One more feature: hardrake script does "modprobe isapnp". On the new 2.4
> kernel the module is now isa-pnp.o
We (HardDrake-Team) already realized it and are working on that ...
--
_
Tschüss und bis demnächst/à bientôt, _|_|_
(") *
Stefan /v\ /
/( )X Penguin Powered!
++(m-m)--+
| Stefan Siegel | http://www.student.uni-kl.de/~siegel/ |
| Kurt-Schumacher-Str. 34 / App. 144 | mailto:[EMAIL PROTECTED] |
| D-67663 Kaiserslautern | PGP Public Key: |
| Tel.: +49-631-18269| finger -l [EMAIL PROTECTED] |
++---+
Re: [Cooker] About CVS initscripts
Pedro Rosa wrote: > > One more feature: hardrake script does "modprobe isapnp". On the new 2.4 > kernel the module is now isa-pnp.o > > Ektanoor Ooops. I'm already sleeping... |Z hardrake is an independent package :T . Anyway note the feature. and besides 2.4.0-test7 has a completely different directory tree for modules. I already fell on it...
Re: [Cooker] About CVS initscripts
One more feature: hardrake script does "modprobe isapnp". On the new 2.4 kernel the module is now isa-pnp.o Ektanoor
Re: [Cooker] About CVS initscripts
Pedro Rosa <[EMAIL PROTECTED]> writes: > Tested on jumping from init level to init level and by making some > manual launches. No visible problems at first sight. There is only one > thing that scratches my head - the /etc/init.d/single. If you launch it > from root, the thing doesn't exactly go to level 1 (at least it leaves > NFS hanging around among other things). The text, inside the script, > suggests such thing. Besides users can launch it (which may TERMINATE > their login environment >:) ). Ough, yet it's one of the reason i need a torturebox machine for this kind of stuff... > Well, in fact, all init.d scripts seem to have world x bit > set. Maybe a more careful approach would be apropriate here? What if > Mr. Clickall decides to visit init.d? Thanks fixed in CVS... > Also. rc.modules is in /etc. Wouldn't be more logical to be on /etc/rc.d Thanks fixed in CVS Thanks you very much for your test... -- MandrakeSoft Inc http://www.chmouel.org San-Francisco, CA USA --Chmouel
Re: [Cooker] About CVS initscripts
Chmouel Boudjnah wrote: > > > ftp://chmouel.org/pub/people/chmou/initscripts-5.27-9mdk.i586.rpm It works. Tested on jumping from init level to init level and by making some manual launches. No visible problems at first sight. There is only one thing that scratches my head - the /etc/init.d/single. If you launch it from root, the thing doesn't exactly go to level 1 (at least it leaves NFS hanging around among other things). The text, inside the script, suggests such thing. Besides users can launch it (which may TERMINATE their login environment >:) ). Well, in fact, all init.d scripts seem to have world x bit set. Maybe a more careful approach would be apropriate here? What if Mr. Clickall decides to visit init.d? Also. rc.modules is in /etc. Wouldn't be more logical to be on /etc/rc.d ? > > > With the exception of these problems, everything else is working from > > start. > > i can't believe that 8-) (8=) Ektanoor
Re: [Cooker] About CVS initscripts
Pedro Rosa <[EMAIL PROTECTED]> writes: > First look at CVS initscripts. > Well I built the initscripts-5.27-9mdk.i686.rpm. The only thing I did > was to remove the references to the patch. I couldn't find where the > thing could be. humm don't build like that, you have to do a make rpm in the mandrake directory. You can give a try to this rpm : ftp://chmouel.org/pub/people/chmou/initscripts-5.27-9mdk.i586.rpm > With the exception of these problems, everything else is working from > start. i can't believe that 8-) -- MandrakeSoft Inc http://www.chmouel.org San-Francisco, CA USA --Chmouel
Re: [Cooker] About CVS initscripts
Pedro Rosa <[EMAIL PROTECTED]> writes: > /etc/init.d/rawdevices has x bits turned off > The CVS directory is copied into init.d in the rpm and gets installed on > the system... thansk fixed in CVS. -- MandrakeSoft Inc http://www.chmouel.org San-Francisco, CA USA --Chmouel
Re: [Cooker] About CVS initscripts
/etc/init.d/rawdevices has x bits turned off The CVS directory is copied into init.d in the rpm and gets installed on the system... Ektanoor
Re: [Cooker] About CVS initscripts
First look at CVS initscripts. Well I built the initscripts-5.27-9mdk.i686.rpm. The only thing I did was to remove the references to the patch. I couldn't find where the thing could be. Now I upgraded the package to my own system (Yeah I'm nuke nuts... (8=E But I took a look before doing it (8=) ). This may not be the best test but... On kernel 2.4.0-test7: network doesn't come up at all. I didn't straightly got how it happened, but the service was turned off during upgrade. NFS didn't came up as the network wasn't working. After raising the devices everything worked. With the exception of these problems, everything else is working from start. Ektanoor
Re: [Cooker] About CVS initscripts
Chmouel Boudjnah wrote: > So the solution i see it to set this as option by default disabled in > /etc/sysconfig/system or make some kind of check i don't like because > /etc/profile.d/ is acceded every time... Maybe the first option is better. In any case it is dangerous to leave it enabled as it may give users some bad surprises. Such "guys" like NFS love to zero file sizes when they get over quota requests. If the user is downloading a $ paperwork this may be a serious hassle for him. And a brainstorm for the sysadmin if the user occurs to be a all-world-know-me-so-how-the-hell-you-dunno-me Professor of Physics... Ektanoor
Re: [Cooker] About CVS initscripts
Pedro Rosa <[EMAIL PROTECTED]> writes: > No the problem is that we are talking here about CVS stuff and most > people are dealing with a completely different version of sources (at > least this is the case). This may create some sort of confusion of the > kind: "What? Where? Why I don't see it? Oh! Ah! Uf!". > Sorry I didn't clarify what I meant by "specific". you know my sentence, cooker is cooker a bunch of ingredients mixed and cooker together > > this is a side i didn't check, you may are right but i don't see > > exactly the problem ? > The problem is the possbility of fast overloads of home directory. > Temporary files are very "specific" to their programs. In cases when > programs can't write to their configuration or temporary files, a set of > problems may arise. Here we have a NFS homedirectory tree (10Mb quota). > When the directories get loaded it is frequent to meet two conditions: > -KDE cleans up its own settings (files in ~/.kde/config are zeroed). In > result the manager either crashes or can't load in next login. > -Netscape starts overloading the system. Sometimes we loose control of > the workstation and only press "anykey" helps. > Several other situations happen, but these are the most frequent. > Besides, the system may get a lot slower in preformance. So the solution i see it to set this as option by default disabled in /etc/sysconfig/system or make some kind of check i don't like because /etc/profile.d/ is acceded every time... -- MandrakeSoft Inc http://www.chmouel.org San-Francisco, CA USA --Chmouel
