root@libove.UUCP (The Super User) (05/13/88)
I tar'ed off my whole SCO Xenix 2.2.1 filesystem and reinstalled only the most basic system from the distribution floppies, then untar'ed the backup back on to the system. I've found that a bunch of empty directories did not get restored... I have a problem somewhere in that with the line printer stuff. I can't get the scheduler running. I've gone so far as to /etc/custom and remove the lp stuff (which failed), then to install it again (which did not complain, so I assume it worked), then /etc/mkdev lp and create a new printer, then enable the printer, but still the scheduler doesn't run (haven't rebooted yet), and when I "lpr filename" it tells me that the default destination (name, correct) is not existant. Fooey. Any helpful suggestions folks? Thanks! Jay Libove (pitt!darth!libove!libove or Jay.Libove@andrew.cmu.edu) -- Jay Libove (Jay.Libove@andrew.cmu.edu or pitt!darth!libove!libove)
jack@turnkey.TCC.COM (Jack F. Vogel) (05/15/88)
In article <22@libove.UUCP> root@libove.UUCP (The Super User) writes: > >I tar'ed off my whole SCO Xenix 2.2.1 filesystem and reinstalled only >the most basic system from the distribution floppies, then untar'ed >the backup back on to the system. I've found that a bunch of empty >directories did not get restored... > >I have a problem somewhere in that with the line printer stuff. >I can't get the scheduler running. Jay, I also had just this sort of problem with turnkey at one point. I believe it is a, shall we say, weakness of tar. Sometimes it does not restore empty directories. For complete filesystem backups it is better to use cpio. And now to the practical advise. When the scheduler fails to start up on boot (it is executed in /etc/rc) or when calling it manually, look in the file /usr/spool/lp/log, it should give you the last message of lpsched and that will aid you in figuring out what is missing. I seem to remember that when this happened to us last it was one of the subdirectories under /usr/spool/lp that was missing. Send me some mail if this doesn't resolve matters for you. Best of luck, -- Jack F. Vogel Turnkey Computer Consultants, Costa Mesa, CA UUCP: ...{nosc|uunet}!turnkey!jack Internet: jack@turnkey.TCC.COM
ben@idsnh.UUCP (Ben Smith) (05/15/88)
In article <22@libove.UUCP> root@libove.UUCP (The Super User) writes: | | I tar'ed off my whole SCO Xenix 2.2.1 filesystem and reinstalled only | the most basic system from the distribution floppies, then untar'ed | the backup back on to the system. I've found that a bunch of empty | directories did not get restored... | | I have a problem somewhere in that with the line printer stuff. | I can't get the scheduler running. You almost have the answer to your problem right here in your question. The problem is that tar will not create empty directories. It just creates directories if they needed to copy files. The print spooler has a number of empty directories to store its spooling information and linked files. In particular is a directory with the "device" name as its name under /usr/spool/lp/request. For instance, the device named laserjet would have a subdirectory of its own: /usr/spool/lp/request/laserjet The best discussion of printer spooling is in David Fiedler's book _UNIX_System_Administration_.
mitchell@cadovax.UUCP (Mitchell Lerner) (05/16/88)
In article <22@libove.UUCP> root@libove.UUCP (The Super User) writes: > >and create a new printer, then enable the printer, but still the >scheduler doesn't run (haven't rebooted yet), and when I "lpr filename" >it tells me that the default destination (name, correct) is not >existant. Fooey. Any helpful suggestions folks? > I think that I had the exact same problem as you do. I think that the fix was that there wasn't a lock file for lpsched isn't there so it thinks that lpsched is already running and rc doesn't start one up for you. Hence nothing exists! Also, use cpio... you'll be alot better off. -- Mitchell Lerner -- UUCP: {ucbvax,ihnp4,decvax}!trwrb!cadovax!mitchell Don't speak to him of your heartache, for he is speaking. He feels the touch of an ants foot. If a stone moves under the water he knows it.
terry@wsccs.UUCP (Every system needs one) (05/28/88)
In article <22@libove.UUCP>, root@libove.UUCP (The Super User) writes: > I have a problem somewhere in that with the line printer stuff. > I can't get the scheduler running. I've gone so far as to /etc/custom > and remove the lp stuff (which failed), then to install it again > (which did not complain, so I assume it worked), then /etc/mkdev lp > and create a new printer, then enable the printer, but still the > scheduler doesn't run (haven't rebooted yet), and when I "lpr filename" > it tells me that the default destination (name, correct) is not > existant. Fooey. Any helpful suggestions folks? 1) reboot If that doesn't work, 2) re-run custom. de-install. re-install. reboot. The reason this may be necessary is that the installation may not have worked (left the old dorked-with files there) when you installed. The reason it didn't complain was that since you re-installed by hand, the file /etc/perms/lp (or some similar beast) wasn't there, so it didn't complain. This is also the reason the de-install threw up in the first place. There is a permissions file which is also run (either an /etc/init* or /tmp/init*) to set the permissions correctly on everything, that probably wouldn't have run, doing it your way. Why are you picking on it anyway? (just curious). | Terry Lambert UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'Admit it! You're just harrasing me because of the quote in my signature!' |
kevinr@june.cs.washington.edu (Kevin Ross) (06/03/88)
In article <22@libove.UUCP>, root@libove.UUCP (The Super User) writes: > I have a problem somewhere in that with the line printer stuff. > I can't get the scheduler running. One thing you might want to try is starting the scheduler manually. I have had a similar problem from time to time. As the root, type the command: # /usr/lib/lpsched Then a #lpstat -t This will tell you if the scheduler started. Kevin School: kevinr@june.cs.washington.edu Home: ..uw-beaver!tikal!camco!carmine!kevin
bill@carpet.WLK.COM (Bill Kennedy) (06/04/88)
In article <5035@june.cs.washington.edu> kevinr@uw-june.UUCP (Kevin Ross) writes: [ just wanted to add something, query deleted ] >As the root, type the command: ># /usr/lib/lpsched >Then a >#lpstat -t >This will tell you if the scheduler started. >Kevin And if the scheduler isn't running, even though you think you started, then look for an old /usr/spool/lp/SCHEDLOCK file and get rid of that and repeat Kevins prescription. If that file exists, you'll have trouble kick starting the scheduler. -- Bill Kennedy Internet: bill@ssbn.WLK.COM Usenet: { killer | att-cb | ihnp4!tness7 }!ssbn!bill
jack@turnkey.TCC.COM (Jack F. Vogel) (06/05/88)
In article <5035@june.cs.washington.edu> kevinr@uw-june.UUCP (Kevin Ross) writes: >In article <22@libove.UUCP>, root@libove.UUCP (The Super User) writes: >> I have a problem somewhere in that with the line printer stuff. >> I can't get the scheduler running. > >One thing you might want to try is starting the scheduler manually. I have >had a similar problem from time to time. I thought I had answered this question before, but perhaps that was a different instance. lpsched should be started at boot time when /etc/rc is run. If it is not then (assuming you have not mucked with the rc file) there is some problem with the spool system and chances are that invoking it manually will not solve the problem. The solution is simple, when lpsched fails at boot it will report the problem in /usr/spool/lp/log. Simply go read that file and it should reveal what the problem is, possibly a missing spool, member, or request directory, etc. Fix the problem, and then call lpsched manually, if need be go back and check the log again, and so on. Best regards, -- Jack F. Vogel Turnkey Computer Consultants, Costa Mesa, CA UUCP: ...{nosc|uunet}!turnkey!jack Internet: jack@turnkey.TCC.COM