michaelb@wshb.csms.com ( WSHB Operations Eng) (07/18/90)
I'm trying to move my /usr/spool directory to a seperate filesystem on a second hard disk in SCO XENIX 386 2.3.2. I didn't have any trouble making the filesystem or getting it to mount. I created all of the directories normally in /usr/spool, set it to automatically mount at boot, and changed cron startup to the user daemons (/etc/rc.d/7) so it would start after the filesystems were stable. I haven't tried to run the system this way because I noticed there is a FIFO in /usr/spool/cron that gets covered when I mount /dev/spool on /usr/spool. I had thought cron would create a new FIFO on startup and remove the old FIFO on shutdown. Obviously I'm wrong. What does this FIFO do? Can I cover it up with impunity, or will cron choke and puke because the FIFO is gone? Is there some way I can trick link to link it across the filesystem boundry? (What the hell is a FIFO anyway? This is one of those magic things about unix I've never understood.) Should I give up on a whole spool directory and just make several smaller filesystems and mount them on uucppublic, mail, and news? Confused in South Carolina. Michael -- Michael Batchelor--Systems/Operations Engineer #compliments and complaints WSHB - An International Broadcast Station of # letterbox@csms.com The Christian Science Monitor Syndicate, Inc. #technical questions and reports michaelb@wshb.csms.com +1 803 625 4880 # letterbox-tech@csms.com
rogerk@sco.COM (Roger Knopf 5502) (07/21/90)
In article <732@wshb.csms.com> michaelb@wshb.csms.com ( WSHB Operations Eng) writes: >I'm trying to move my /usr/spool directory to a seperate filesystem on a >second hard disk in SCO XENIX 386 2.3.2. I didn't have any trouble >making the filesystem or getting it to mount. I created all of the >directories normally in /usr/spool, set it to automatically mount >at boot, and changed cron startup to the user daemons (/etc/rc.d/7) >so it would start after the filesystems were stable. I haven't tried >to run the system this way because I noticed there is a FIFO in >/usr/spool/cron that gets covered when I mount /dev/spool on /usr/spool. > >I had thought cron would create a new FIFO on startup and remove the old FIFO >on shutdown. Obviously I'm wrong. What does this FIFO do? Can I cover >it up with impunity, or will cron choke and puke because the FIFO is >gone? Is there some way I can trick link to link it across the filesystem >boundry? (What the hell is a FIFO anyway? This is one of those magic >things about unix I've never understood.) First: a FIFO is a named pipe. Programs (such as crontab) can write to it and other programs (such as cron) can read from it without knowing directly about each other as you would to establish a regular pipe. The FIFO is there for crontab to communicate with cron. You can make it in your new filesystem by doing: # /etc/mknod FIFO p # chown root FIFO # chgrp bin FIFO # chmod 755 FIFO or even easier, after you have mounted your spool file system: # cd / # /etc/fixperm -cs -dRTS /etc/perms/rts -- Roger Knopf <standard disclaimer applies> SCO Consulting Services "The True Believers will...formulate uunet!sco!rogerk or rogerk@sco.com a message that even a monkey could 408-425-7222 (voice) 408-458-4227 (fax) understand." --Jeff Tye
rogerk@sco.COM (Roger Knopf 5502) (07/25/90)
In article <8224@scorn.sco.COM> I wrote: > >In article <732@wshb.csms.com> michaelb@wshb.csms.com ( WSHB Operations Eng) writes: >>I'm trying to move my /usr/spool directory to a seperate filesystem on a >>second hard disk in SCO XENIX 386 2.3.2. > >The FIFO is there for crontab to communicate with cron. You can make >it in your new filesystem by doing: [ useless technical stuff deleted ] Chip Rosenthal wisely pointed out that since cron starts before the file systems are mounted, my above solution won't work. He suggests either to hack /etc/rc.d to reverse the order (and neither he nor I recommend doing this) or pick some lower directory than /usr/spool (/usr/spool/news) and make _that_ the mounted file system. Thanks for the assist, Chip. -- Roger Knopf <standard disclaimer applies> SCO Consulting Services "The True Believers will...formulate uunet!sco!rogerk or rogerk@sco.com a message that even a monkey could 408-425-7222 (voice) 408-458-4227 (fax) understand." --Jeff Tye
jbayer@ispi.COM (Jonathan Bayer) (07/26/90)
rogerk@sco.COM (Roger Knopf 5502) writes: >In article <8224@scorn.sco.COM> I wrote: >> >>In article <732@wshb.csms.com> michaelb@wshb.csms.com ( WSHB Operations Eng) writes: >>>I'm trying to move my /usr/spool directory to a seperate filesystem on a >>>second hard disk in SCO XENIX 386 2.3.2. >> >>The FIFO is there for crontab to communicate with cron. You can make >>it in your new filesystem by doing: >[ useless technical stuff deleted ] >Chip Rosenthal wisely pointed out that since cron starts before the >file systems are mounted, my above solution won't work. He suggests >either to hack /etc/rc.d to reverse the order (and neither he nor >I recommend doing this) or pick some lower directory than /usr/spool >(/usr/spool/news) and make _that_ the mounted file system. There is yet _another_ solution :-) I admit it is not the best, but is do-able. What you have to do is to create the /usr/spool/cron directory structure on the root filesystem, as well as having it on the mounted filesystem. What is a pain is making sure that both sets of directories are identical, so when you boot up cron sees a correct file. I would suggest doing it in one of two places: 1. Modify the shutdown script to unmount the filesystem, mount it again as /u, and do a "copy -omr /u/cron /usr/spool/cron" 2. Modify the rc.d/2/mntfs to first mount the directory in /u, then do a similar copy as # 1, then have a script go through the /usr/spool/cron/crontabs and do a "crontab $..." in order to tell cron about any possible changes. I would really recommend doing both of these steps in order to avoid missing anything. The only problem with # 2 is that it might miss some "at" jobs. BTW, since cron is started _just_ before the filesystems are mounted, would there be a big problem in starting cron _after_ they are mounted? I realize that the /etc/rc.d directories are set up in a fairly logical order, but that order could be moved around a bit without any real problems. JB -- Jonathan Bayer Intelligent Software Products, Inc. (201) 245-5922 500 Oakwood Ave. jbayer@ispi.COM Roselle Park, NJ 07204
gary@cdthq (gary) (07/27/90)
jbayer@ispi.COM (Jonathan Bayer) writes: > BTW, since cron is started _just_ before the filesystems are mounted, > would there be a big problem in starting cron _after_ they are mounted? > I realize that the /etc/rc.d directories are set up in a fairly logical > order, but that order could be moved around a bit without any real > problems. No. I can't see any possible way that mount depends on cron. Gary Heston, at home
gar@spiff.UUCP (Gordon Runkle) (07/28/90)
In article <8353@scorn.sco.COM> rogerk@sco.COM (Roger Knopf 5502) writes:
Chip Rosenthal wisely pointed out that since cron starts before the
file systems are mounted, my above solution won't work. He suggests
either to hack /etc/rc.d to reverse the order (and neither he nor
I recommend doing this) or pick some lower directory than /usr/spool
(/usr/spool/news) and make _that_ the mounted file system.
Why is putting the cron startup after the filesystems mount bad? I've
had mine this way for over a year, and haven't had any difficulty at
all with it.
Inquiring minds and all that rot...
-=gordon=-
--
Gordon A. Runkle, Runkle Research UUCP: uunet!men2a!spiff!gar
INTERNET: men2a!spiff!gar@uunet.uu.net, gar%spiff%men2a@uunet.uu.net
PH: 703-522-0825 OR 202-566-4382 bblue@crash.cts.com (Bill Blue) (07/30/90)
In article <1654@ispi.COM> jbayer@ispi.COM (Jonathan Bayer) writes: >I admit it is not the best, but is do-able. What you have to do is to >create the /usr/spool/cron directory structure on the root filesystem, >as well as having it on the mounted filesystem. What is a pain is >making sure that both sets of directories are identical, so when you >boot up cron sees a correct file. I would suggest doing it in one of >two places: > > 1. Modify the shutdown script to unmount the filesystem, mount > it again as /u, and do a "copy -omr /u/cron /usr/spool/cron" > > 2. Modify the rc.d/2/mntfs to first mount the directory in /u, > then do a similar copy as # 1, then have a script go through > the /usr/spool/cron/crontabs and do a "crontab $..." in > order to tell cron about any possible changes. > >I would really recommend doing both of these steps in order to avoid >missing anything. The only problem with # 2 is that it might miss some >"at" jobs. Why on earth do all this stuff? >BTW, since cron is started _just_ before the filesystems are mounted, >would there be a big problem in starting cron _after_ they are mounted? >I realize that the /etc/rc.d directories are set up in a fairly logical >order, but that order could be moved around a bit without any real >problems. Just move the cron startup to rc.d/8/userdef. It really doesn't matter that cron is started up just after the mount. Here on crash, I have the entire /usr/spool hierarchy on a separate mount. There is no need for another 'hidden' /usr/spool to be there before the real one gets mounted. Just mount, start cron, and go on your way. Nothing in single user mode without the mount mounted misses it. I did it this way for a couple of reasons. For one, it keeps all the transient spool stuff from fragmenting the root filesystem. Those who optimize the harddrives for maximum throughput, will realize how badly fragmentation affects performance. Having a separate /usr/spool helps a lot to maintain / performance. It also gives you the flexibility of growing that space as your spool demands increase, without the need of moving the root files around. --Bill
chip@chinacat.Unicom.COM (Chip Rosenthal) (08/04/90)
In article <GAR.90Jul27181633@spiff.UUCP> gar@spiff.UUCP (Gordon Runkle) writes: >In article <8353@scorn.sco.COM> rogerk@sco.COM (Roger Knopf 5502) writes: > He suggests either to hack /etc/rc.d to reverse the order (and neither he > nor I recommend doing this) or pick some lower directory than /usr/spool > (/usr/spool/news) and make _that_ the mounted file system. >Why is putting the cron startup after the filesystems mount bad? A bit of context. I was reading into the situation that it was the size of /usr/spool/news which was pushing the original poster into creating a /usr/spool filesystem. If that was the case, I suggested that making it just a news filesystem was a good idea for two reasons: first it doesn't break /etc/rc.d/*, and second if your filesystem fills you aren't going to get mail messages and such dropped on the floor. Certainly, starting cron after the mount would work, and arguably that's a much more sensible sequence. But I'm a strong believer of keeping news off in a seperate corner. I'm a subscriber to the "Gaseous Theory of USENET" (news expands to occupy the available volume). -- Chip Rosenthal | You aren't some icon carved out chip@chinacat.Unicom.COM | of soap, sent down here to clean Unicom Systems Development, 512-482-8260 | up my reputation. -John Hiatt