3B1 print scheduler

[Dennis Lefebvre]

lpstat -t reports "scheduler is not running" and I am unable to print.
I have tried executing /usr/lib/lpsched (while logged in as root) but
this appeared to have no effect. What else can I try to restart the
process and what might have stopped it?

[DoN. Nichols]

It has been a long time since I last used my 3B1s, but I think
that is is one of the things started from /etc/inittab. A pity the 3B1s
never had the on-line man pages, because the normal advice would be to
type "man lpsched". Do you have the development set with the system,
including all the manuals there. That is where the man pages (in
printed format) are available. Most unix systems have them in a
directory tree like /usr/lib/man with a subdirectory for each category
(e.g. commands, system calls, library routines, files, games, etc),
where they are stored as nroff/troff source and nroff is used to format
them for display. (I added a man command and some man pages for
imported programs, but never found the ones for the 3B1's own commands
on line. It is kind of late to look it up right now. If you can't find
it, post here again and I'll try to find it in the dead tree manuals.

Good Luck,
DoN.

--
Remove oil spill source from e-mail
Email: <BPdnic...@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

[Willard Frank Goosey III]

It was many moons ago that I played with that, but it did work for
me... I don't have a 3b1 set up right now. :-(

IIRC I set it all up through the "install" user. Try playing with the
lpadmin and accept commands... I seem to remember that you may need to
be user lp instead of root to configure it by hand. Trace through the
UA scripts.

Willard
--
goo...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

[Dennis Lefebvre]

I have the printed Users Manual in two volumes, and have read the
discussion of lpadmin, lpsched, and accept. The documentation does
not mention the requirement to login as lp which Willard mentions,
also mentioned in the 3B1 FAQ. This does not seem to make any
difference, but perhaps I do not correctly understand the process.
First I login as root, then at the # prompt I type: su lp which
displays a $ prompt at which I enter the commands.

Each time I execute the command /usr/lib/lpsched a line is written to /
usr/spool/lp/log: ***** STOPPED Feb 28 17:41 ***** There is no other
type of entry in the log. I take this to mean that another process is
killing lpsched -or- lpsched is not finding something it expects, but
the output from ps -e is no different than on another 3B1 except that
lpsched is not listed.

In the discussion of lpadmin I read about switch l "indicates that the
device associated with P(rinter) is a login terminal. The LP
scheduler, lpsched, disables all login terminals automatically each
time it is started. Before re-enabling P, its current device should be
established using lpadmin." I cannot say I fully understand this, but
I was in process of configuring the serial ports (though the GUI) when
the print scheduler became disabled.

All further suggestions appreciated.

dennis

On Feb 25, 12:18 am, "DoN. Nichols" <BPdnichol...@d-and-d.com> wrote:
> On 2012-02-24, Dennis Lefebvre <uni...@gmail.com> wrote:
>
> > lpstat -t reports "scheduler is not running" and I am unable to print.
> > I have tried executing /usr/lib/lpsched (while logged in as root) but
> > this appeared to have no effect. What else can I try to restart the
> > process and what might have stopped it?
>
>         It has been a long time since I last used my 3B1s, but I think
> that is is one of the things started from /etc/inittab.  A pity the 3B1s
> never had the on-line man pages, because the normal advice would be to
> type "man lpsched".  Do you have the development set with the system,
> including all the manuals there.  That is where the man pages (in
> printed format) are available.  Most unix systems have them in a
> directory tree like /usr/lib/man with a subdirectory for each category
> (e.g. commands, system calls, library routines, files, games, etc),
> where they are stored as nroff/troff source and nroff is used to format
> them for display.  (I added a man command and some man pages for
> imported programs, but never found the ones for the 3B1's own commands
> on line.  It is kind of late to look it up right now.  If you can't find
> it, post here again and I'll try to find it in the dead tree manuals.
>
>         Good Luck,
>                 DoN.
>
> --
>                   Remove oil spill source from e-mail

>  Email: <BPdnichol...@d-and-d.com>   | Voice (all times): (703) 938-4564

[DoN. Nichols]

On 2012-02-28, Dennis Lefebvre <uni...@gmail.com> wrote:
> I have the printed Users Manual in two volumes, and have read the
> discussion of lpadmin, lpsched, and accept.

O.K. You have everything that I do, plus a running system or
two.

> The documentation does
> not mention the requirement to login as lp which Willard mentions,
> also mentioned in the 3B1 FAQ. This does not seem to make any
> difference, but perhaps I do not correctly understand the process.
> First I login as root, then at the # prompt I type: su lp which
> displays a $ prompt at which I enter the commands.
>
> Each time I execute the command /usr/lib/lpsched a line is written to /
> usr/spool/lp/log: ***** STOPPED Feb 28 17:41 ***** There is no other
> type of entry in the log. I take this to mean that another process is
> killing lpsched -or- lpsched is not finding something it expects, but
> the output from ps -e is no different than on another 3B1 except that
> lpsched is not listed.

Hmmm ... trying to remember whether the 3B1 includes strings in
its collection of utilities. If so, try the following:

strings /usr/lib/lpsched | grep '/' | more (or preferably "less",
if you have it).

This should show all files referenced by the program, and all
directories which it looks at. Then compare those files between the
working and the non-working systems. I suspect that there is a
corrupted file which is causing lpsched to stop and exit.

There may be a "files" section on the man page for lpsched which
would save you doing the strings trick.

Also -- I didn't ask what device you were trying to print to.
The parallel port? one of the serial ports? (One perhaps on a card
like the COMBO card which might not be present but was when the printer
was last configured.

> In the discussion of lpadmin I read about switch l "indicates that the
> device associated with P(rinter) is a login terminal.

Hmm ... if /etc/ttys (or was the login watch set in
/etc/inittab?) is trying to use the serial port as a login port, that
could be problems.

Also -- run "sum" on both copies of /usr/lib/lpsched to make
sure that they are the same. If not, replace the one on the non-working
system with a copy from the working system.

It has been at least twenty years, and more like thirty since I
ran a 3B1 connected to a printer.

> The LP
> scheduler, lpsched, disables all login terminals automatically each
> time it is started. Before re-enabling P, its current device should be
> established using lpadmin." I cannot say I fully understand this, but
> I was in process of configuring the serial ports (though the GUI) when
> the print scheduler became disabled.

Hmm ... that could be it. You are using a serial printer, not a
parallel one?

What does lpadmin say is currently selected as the printer port?
Is that one also configured as a login port?

> All further suggestions appreciated.

You have my thoughts above.

Good Luck,
DoN.

--
Remove oil spill source from e-mail

Email: <BPdnic...@d-and-d.com> | Voice (all times): (703) 938-4564

[Dennis Lefebvre]

Context: We first acquired a 3B1 in 1988 and have used one
continuously to run a customized software application.(I know this
defies commonsense.We "solved" Y2K incompatibility in our application
software by setting the system year to 1980. It is now 1992.)

Today, we typically have one unit in service with one parallel and one
serial printer attached. A second fully operational unit is kept ready
to swap in on failure, and others are in various states.

The built-in serial (TTY000) is used for the serial printer. We use
two RS232 COMBO expansion boards which adds four more serial ports, of
which three are used for terminal access (Windows PCs running Kermit
95). We were not always consistent about which serial port was used
for the printer and there is an anomaly. "Install" shows an obsolete
printer ATT455 on TTY002 even though that port is actually used by a
terminal. I do not think this is directly relevant to this problem
because the anomaly also appears in the unit with the scheduler
running.

strings is not included in this version of Unix. MAN files list shows /
usr/spool/lp/* and there are differences in the file lists on two
units. On the machine with the scheduler running there are two
additional files in /usr/spool/lp:

-rw------- 1 lp other 0 Feb 29 12:48 FIFO
-r--r--r-- 1 lp other 4 Feb 29 08:57 SCHEDLOCK

I assume these files are created by /usr/lib/lpsched. I tried copying
them onto the unit, but no effect and they were deleted when the
machine was restarted.

Both copies of /usr/lib/lpsched report the same checksum.

>  Email: <BPdnichol...@d-and-d.com>   | Voice (all times): (703) 938-4564

[DoN. Nichols]

On 2012-02-29, Dennis Lefebvre <uni...@gmail.com> wrote:
> Context: We first acquired a 3B1 in 1988 and have used one
> continuously to run a customized software application.(I know this
> defies commonsense.We "solved" Y2K incompatibility in our application
> software by setting the system year to 1980. It is now 1992.)

O.K. Some parts could be fixed (for locally compiled programs)
by installing a more modern libctime and such and I had such back when I
was running mine to keep the DST switch at the right time for those
programs (and recompiling date and a few others could get around a lot
of problems.)

The system itself can keep going well past Y2K, except for a
program which tries to reset the battery backed up time chip, which is
*not* Y2K compliant. Last time I had to bring one of the systems up (a
few years ago) I managed to make some programs to force it past Y2K, but
it was kludgy.

> Today, we typically have one unit in service with one parallel and one
> serial printer attached. A second fully operational unit is kept ready
> to swap in on failure, and others are in various states.
>
> The built-in serial (TTY000) is used for the serial printer. We use
> two RS232 COMBO expansion boards which adds four more serial ports, of
> which three are used for terminal access (Windows PCs running Kermit
> 95). We were not always consistent about which serial port was used
> for the printer and there is an anomaly. "Install" shows an obsolete
> printer ATT455 on TTY002 even though that port is actually used by a
> terminal. I do not think this is directly relevant to this problem
> because the anomaly also appears in the unit with the scheduler
> running.

O.K. Can you get it to remove that one, just to be sure?
Probably not the source of the problem, but it should be fixed.

> strings is not included in this version of Unix.

But is easily compiled for it. Probably the best source would
be the GNU binutils suite. Yep -- I just checked, and it is there. If
you need an old set, I have one from about 1996. You *do* have the
development set, don't you?

> MAN files list shows /
> usr/spool/lp/* and there are differences in the file lists on two
> units. On the machine with the scheduler running there are two
> additional files in /usr/spool/lp:
>
> -rw------- 1 lp other 0 Feb 29 12:48 FIFO
> -r--r--r-- 1 lp other 4 Feb 29 08:57 SCHEDLOCK
>
> I assume these files are created by /usr/lib/lpsched. I tried copying
> them onto the unit, but no effect and they were deleted when the
> machine was restarted.

SCHEDLOCK is a lockfile to keep two copies of the lp scheduling
daemon from running at the same time. The four bytes are probably the
UID of the program which created it and a terminating NULL.
The other is a "named pipe" or a
FIFO (First In First Out), which is created by the program, and which
goes away when the starting program dies. It can only be read by one
program, and only written by another program.

Your "copy", which is not a true FIFO, is probably removed
before the daemon tries to start, then when the FIFO starts it creates
it, dies for whatever other reason, and removed it in its death throes.

the file(1) command should be able to tell you that. Or extra
options to the ls(1) command should also tell you that. Hmm ... it
*should* put a 'm' in place of the '-' as the first character of the
modes. Is this by any chance the listing from the system with problems,
so this would be a plain text file instead of a special file?

Look at the man page for mknod(2) and you will find an option to
it for creating a fifo (mode 0010000). Note that mknod(2) is not a
command, but a system call, and so you need to compile it into a program
to use it.

> Both copies of /usr/lib/lpsched report the same checksum.

Check the ownership and permissions on the directory, and all
files leading up to it, to make sure that either the UID for lp, or the
GID for other can write to the /usr/spool/lp. (First verifying that
those are the correct ownerships in the working system).

I can't seem to find the lpsched man page for the 3B1. (I've
always suspected that my copies of the manuals are not complete. Are
there any options to lpsched which could get it to produce more useful
error messages -- perhaps by not going into background mode as a daemon
normally does.

O.K. The man page for lpsched on Sun's Solaris 2.6 does not
include any options for reporting problems. Even the one for Sun's
Solaris 10 does not have any reporting options, though it does have
options for other purposes.

So -- not much else to check, but something.

Good Luck,
DoN.

--
Remove oil spill source from e-mail

Email: <BPdnic...@d-and-d.com> | Voice (all times): (703) 938-4564

[Willard Frank Goosey III]

"DoN. Nichols" <BPdnic...@d-and-d.com> writes:

>> The built-in serial (TTY000) is used for the serial printer.

Make sure you're not running a getty on it.

> I can't seem to find the lpsched man page for the 3B1. (I've
>always suspected that my copies of the manuals are not complete. Are

It's in User's Manual Volume 1.

>there any options to lpsched which could get it to produce more useful
>error messages -- perhaps by not going into background mode as a daemon
>normally does.

Nope. :-(

[Willard Frank Goosey III]

Does lpstat say anything useful?

[Dennis Lefebvre]

$ lpstat -t
scheduler is not running
system default destination: Other
members of class Serial:
Epson
members of class Serial2:
ATT455
members of class Parallel:
Other
device for Epson: /dev/tty000
device for ATT455: /dev/tty000
device for Other: /dev/lp
Epson accepting requests since Feb 25 16:51
Serial accepting requests since Feb 25 16:51
Other accepting requests since Feb 28 17:58
Parallel accepting requests since Feb 28 17:58
printer Epson is idle. enabled since Feb 25 16:51
printer Other is idle. enabled since Feb 28 17:58

I uninstalled the Combo board drivers because I noticed at that doing
so displayed a message warning that it would "temporarily" stop the
print scheduler, and I hoped it would then restart it. During the
uninstall it displayed: ATT455 not a request ID or destination.
Reinstalled the drivers and print scheduler still not running. Note
that even though lpstat reports device for ATT455 as tty000, the
graphical interface shows it on tty002. (When I replaced the original
AT&T printers I don't recall creating any new entries, I believe I
just set them to emulate the same printers as the AT&T models were set
to emulate. It may be that Epson and ATT455 are two names for the same
profile.)

It does not appear that getty is running on TTY000:

PID TTY TIME COMMAND
0 ? 7845:53 swapper
1 ? 0:17 init
2 ? 0:00 pagedaemon
3 ? 2:38 windaemon
5202 w1 0:01 getty
116 ? 0:01 getty
5169 004 0:01 getty
102 w4 0:01 wmgr
104 w5 12:25 smgr
99 w3 0:01 .phclr
6180 003 0:05 sh
6121 001 0:05 sh
6779 003 1:47 Maint
6875 003 0:00 sh
6876 003 0:00 sh
6838 001 3:53 MAINT
6887 003 0:02 sh
6888 003 0:01 ps

# cat inittab
:sccs "@(#)fndetc:inittab 1.2"
: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
: DO NOT EDIT THIS FILE!!! IT IS PROGRAM-MODIFIED!!!!!
:
: The following states are used :
: s = single user
: 2 = general single or multiple user mode
: REPEAT: DO NOT EDIT THIS FILE!!! IT IS PROGRAM-MODIFIED!!!!!
is:2:initdefault:
vid:2:respawn:/etc/getty window 9600
:ph0:2:respawn:/etc/getty ph0 1200
ph1:2:respawn:/etc/getty ph1 1200
rc::bootwait:/etc/rc > /dev/null 2>&1
:000:2:respawn:/etc/getty tty000 9600
:002:2:respawn:/etc/getty tty002 9600
001:2:respawn:/etc/getty tty001 9600
003:2:respawn:/etc/getty tty003 9600
004:2:respawn:/etc/getty tty004 9600

It will take me a few days to followup some of Don's suggestions.

dennis


On Mar 1, 11:40 pm, Willard Frank Goosey III <goo...@sdf.lonestar.org>
wrote:

[DoN. Nichols]

On 2012-03-02, Dennis Lefebvre <uni...@gmail.com> wrote:
> $ lpstat -t
> scheduler is not running
> system default destination: Other
> members of class Serial:
> Epson
> members of class Serial2:
> ATT455
> members of class Parallel:
> Other
> device for Epson: /dev/tty000
> device for ATT455: /dev/tty000

Hmm ... this is bad -- having both printers on the same port.

Can you use lpadmin to remove both the Epson and the ATT455? (I
wonder whether the ATT455 is really an Epson with a new label?) Anyway
remove all the printers, then add back only what you have.

Is there more than one lp* directory in /usr/spool? In the
oldest SysV which I am still running, a Solaris 2.6, I find the
following from (find /var -name lp\* -print):

======================================================================
/var/adm/lpd-errs
/var/spool/cron/crontabs/lp
/var/spool/lp
/var/spool/lp/admins/lp
/var/lp
/var/lp/logs/lpsched
/var/lp/logs/lpsched.1
/var/lp/logs/lpsched.2
======================================================================

(and /var is where the things which used to be in /usr/spool were moved
to). You might try that find run with "/var" changed to "/usr/spool" to
see what else is there for printer control.

You might also try this

find /usr/spool -type f -print | xargs grep "ATT455" to see
whether there are any files which configure the ATT455 into the spool.

> device for Other: /dev/lp
> Epson accepting requests since Feb 25 16:51
> Serial accepting requests since Feb 25 16:51
> Other accepting requests since Feb 28 17:58
> Parallel accepting requests since Feb 28 17:58
> printer Epson is idle. enabled since Feb 25 16:51
> printer Other is idle. enabled since Feb 28 17:58
>
> I uninstalled the Combo board drivers because I noticed at that doing
> so displayed a message warning that it would "temporarily" stop the
> print scheduler, and I hoped it would then restart it.

That could have caused the ATT455 to be moved from "/tty002" (or
whatever it was that vanished) to "/tty000" rather than simply
unconfiguring the ATT455. Removing that might help.

> During the
> uninstall it displayed: ATT455 not a request ID or destination.
> Reinstalled the drivers and print scheduler still not running. Note
> that even though lpstat reports device for ATT455 as tty000, the
> graphical interface shows it on tty002. (When I replaced the original
> AT&T printers I don't recall creating any new entries, I believe I
> just set them to emulate the same printers as the AT&T models were set
> to emulate. It may be that Epson and ATT455 are two names for the same
> profile.)

Try using lpadm (or the GUI scripts) to remove that printer
totally. It could be confusing things. "lpsched" tries to open two
printers on the same port, and then bails. (Come to think of it, is
there a log file maintained by lpsched?)

It looks as though

lpadmin -x ATT455

should get rid of it.

Hmm ... looking more closely at the lpadmin(1M) program's man
page, I also see among the options:

-l indicates that the device associated with P is a login
terminal. The LP scheduler, lpsched, disables all login

terminals automatically each time it is started. Before
re-enabling P, its current device should be established
using lpadmin.

Hmm ... also:

-v associates a new device with printer P. Device is the
pathname of a file that is writable by the LP
adminstrator, lp. Note that there is nothing to stop an
administator from associating the same device with more
than one printer. If only the -p and -v options are
specified, then lpadmin may be used while the scheduler
is running.

Anyway -- that reminds me -- who owns the /dev/tty??? ports
which the printers are allocated to? They should all be owned by "lp",
and removing and replacing the COMBO card serial ports may force a
change in the ownership. (Also what group? also "lp"?)

> It does not appear that getty is running on TTY000:
>
> PID TTY TIME COMMAND
> 0 ? 7845:53 swapper
> 1 ? 0:17 init
> 2 ? 0:00 pagedaemon
> 3 ? 2:38 windaemon
> 5202 w1 0:01 getty
> 116 ? 0:01 getty
> 5169 004 0:01 getty
> 102 w4 0:01 wmgr
> 104 w5 12:25 smgr
> 99 w3 0:01 .phclr
> 6180 003 0:05 sh
> 6121 001 0:05 sh
> 6779 003 1:47 Maint
> 6875 003 0:00 sh
> 6876 003 0:00 sh
> 6838 001 3:53 MAINT
> 6887 003 0:02 sh
> 6888 003 0:01 ps

It can't, if the printer is also trying to use it, based on the
-v option to lpadmin quoted above.

> # cat inittab
>:sccs "@(#)fndetc:inittab 1.2"
>: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>: DO NOT EDIT THIS FILE!!! IT IS PROGRAM-MODIFIED!!!!!
>:
>: The following states are used :
>: s = single user
>: 2 = general single or multiple user mode
>: REPEAT: DO NOT EDIT THIS FILE!!! IT IS PROGRAM-MODIFIED!!!!!
> is:2:initdefault:
> vid:2:respawn:/etc/getty window 9600
>:ph0:2:respawn:/etc/getty ph0 1200
> ph1:2:respawn:/etc/getty ph1 1200
> rc::bootwait:/etc/rc > /dev/null 2>&1
>:000:2:respawn:/etc/getty tty000 9600
>:002:2:respawn:/etc/getty tty002 9600
> 001:2:respawn:/etc/getty tty001 9600
> 003:2:respawn:/etc/getty tty003 9600
> 004:2:respawn:/etc/getty tty004 9600

It is commented out, as is tty002.

> It will take me a few days to followup some of Don's suggestions.

And here I got spewing out a few more.

[Dennis Lefebvre]

I have tried to recreate what I when doing when the scheduler stopped.
In fact, I was trying to remove the phantom ATT455 printer from Serial
Port 2 using the UA. This is done by setting the device on the port to
NONE. It then displayed an error cautioning that it was connected to a
Terminal (even though I was removing a printer). After I completed the
process the ATT455 is still shown on Port 2 and the print scheduler is
stopped.

The UA script which performs this function is RSfree.sh. I don't have
much programming background but it appears that it attempts the
removal with /usr/lib/lpadmin -x and later executes /usr/lib/lpsched
which should restart the scheduler. Normally the scheduler can be
restarted by using UA Printer Restart command, but that does not
work. /usr/bin/Pclear.sh is the script used by the UA Restart Printers
command which appears to:

1. execute /usr/lib/lpshut
2. enable each printer
3. execute /usr/lib/lpsched

Please mention if you would like me to post or email either of the
scripts.

Searching as Don suggested:

find /usr/spool -type f -print | xargs grep "ATT455"

/usr/spool/lp/class/Serial2:ATT455
/usr/spool/lp/baudrates:9600=/dev/tty002 ATT455

/usr/spool/lp/baudrates is a text file

9600=/dev/tty000 Epson
9600=/dev/tty001 NONE
9600=/dev/tty002 ATT455
9600=/dev/tty003 NONE
9600=/dev/tty004 NONE
9600=/dev/tty005 NONE
9600=/dev/tty006 NONE

Here are the ownership and permissions of all the directories in /usr/
spool/lp/request (all are identical to another system)

drwxrwxrwx 16 bin bin 256 Sep 22 11:04 usr/
drwxrwxr-x 5 root bin 80 Apr 20 1987 spool/
drwxr-xr-x 7 lp bin 336 Mar 6 10:51 lp/
drwxr-xr-x 7 lp bin 128 Feb 28 17:58 request/
drwxr-xr-x 2 lp other 1184 Mar 6 10:51 Epson/
drwxr-xr-x 2 lp other 336 Mar 5 16:26 Other/

And the ports:

c-w--w--w- 1 root sys 6, 0 Feb 24 10:25 lp
crw-rw-rw- 1 root 101 0, 0 Mar 3 17:48 tty000
crw-rw-rw- 1 root 101 0, 2 Mar 6 17:07 tty001
crw-rw-rw- 1 root users 0, 3 Feb 29 17:45 tty002
crw-rw-rw- 1 djl 101 0, 4 Mar 6 17:31 tty003
crw-rw-rw- 1 root users 0, 5 Mar 2 15:27 tty004


I verified that executing /usr/lib/lpsched does start the scheduler
*very* briefly (a second?) and three files are created and promptly
disappear. It makes no difference if I am logged in as an ordinary
user, root, or lp.

#/usr/lib/lpsched
# ls -l
total 31
-rw------- 1 lp other 3 Mar 6 15:35 FIFO
-r--r--r-- 1 lp other 4 Mar 6 15:35 OUTQLOCK
-r--r--r-- 1 lp other 4 Mar 6 15:35 SCHEDLOCK
-rw-r--r-- 1 lp other 158 Mar 3 15:38 baudrates
drwxr-xr-x 2 lp bin 80 Feb 28 17:58 class
-rw-r--r-- 1 lp other 6 Feb 28 17:58 default
drwxr-xr-x 2 lp bin 80 Feb 28 17:58 interface
-rw-r--r-- 1 lp other 2889 Mar 6 15:34 log
drwxr-xr-x 2 lp bin 80 Feb 28 17:58 member
drwxr-xr-x 2 lp bin 144 Sep 22 08:32 model
-rw-r--r-- 1 lp other 237 Feb 24 10:44 oldlog
-rw-r--r-- 1 lp other 1748 Mar 6 15:35 outputq
-rw-r--r-- 1 lp other 256 Mar 3 18:49 pstatus
-rw-r--r-- 1 lp other 416 Feb 28 17:58 qstatus
drwxr-xr-x 7 lp bin 128 Feb 28 17:58 request
-rw-r--r-- 1 lp bin 5 Mar 6 15:24 seqfile

[DoN. Nichols]

On 2012-03-06, Dennis Lefebvre <uni...@gmail.com> wrote:
> I have tried to recreate what I when doing when the scheduler stopped.
> In fact, I was trying to remove the phantom ATT455 printer from Serial
> Port 2 using the UA. This is done by setting the device on the port to
> NONE. It then displayed an error cautioning that it was connected to a
> Terminal (even though I was removing a printer). After I completed the
> process the ATT455 is still shown on Port 2 and the print scheduler is
> stopped.

O.K.

> The UA script which performs this function is RSfree.sh. I don't have
> much programming background but it appears that it attempts the
> removal with /usr/lib/lpadmin -x and later executes /usr/lib/lpsched
> which should restart the scheduler. Normally the scheduler can be
> restarted by using UA Printer Restart command, but that does not
> work. /usr/bin/Pclear.sh is the script used by the UA Restart Printers
> command which appears to:
>
> 1. execute /usr/lib/lpshut
> 2. enable each printer
> 3. execute /usr/lib/lpsched
>
> Please mention if you would like me to post or email either of the
> scripts.

Certainly not e-mail. The only way I could check them would be
by digging up and brining up my 3B1 system -- and it has been a *long*
time since it was connected to a computer -- and I had to re-install
anyway after a disk crash.

> Searching as Don suggested:
>
> find /usr/spool -type f -print | xargs grep "ATT455"
> /usr/spool/lp/class/Serial2:ATT455
> /usr/spool/lp/baudrates:9600=/dev/tty002 ATT455
>
> /usr/spool/lp/baudrates is a text file
>
> 9600=/dev/tty000 Epson
> 9600=/dev/tty001 NONE
> 9600=/dev/tty002 ATT455
> 9600=/dev/tty003 NONE
> 9600=/dev/tty004 NONE
> 9600=/dev/tty005 NONE
> 9600=/dev/tty006 NONE

O.K. Edit it to change the /dev/tty002 entry to read NONE as do
most of the others.

> Here are the ownership and permissions of all the directories in /usr/
> spool/lp/request (all are identical to another system)
>
> drwxrwxrwx 16 bin bin 256 Sep 22 11:04 usr/
> drwxrwxr-x 5 root bin 80 Apr 20 1987 spool/
> drwxr-xr-x 7 lp bin 336 Mar 6 10:51 lp/
> drwxr-xr-x 7 lp bin 128 Feb 28 17:58 request/
> drwxr-xr-x 2 lp other 1184 Mar 6 10:51 Epson/
> drwxr-xr-x 2 lp other 336 Mar 5 16:26 Other/
>
> And the ports:
>
> c-w--w--w- 1 root sys 6, 0 Feb 24 10:25 lp
> crw-rw-rw- 1 root 101 0, 0 Mar 3 17:48 tty000
> crw-rw-rw- 1 root 101 0, 2 Mar 6 17:07 tty001
> crw-rw-rw- 1 root users 0, 3 Feb 29 17:45 tty002
> crw-rw-rw- 1 djl 101 0, 4 Mar 6 17:31 tty003
> crw-rw-rw- 1 root users 0, 5 Mar 2 15:27 tty004

Any clue who group 101 is supposed to be? That should be in
the /etc/group file, but the fact that it is shown as a numeric value
says that it is not in there. Looks like it is a group which belongs to
/etc/getty. Change the group on /dev/tty002 to be 101 as well.

>
> I verified that executing /usr/lib/lpsched does start the scheduler
> *very* briefly (a second?) and three files are created and promptly
> disappear. It makes no difference if I am logged in as an ordinary
> user, root, or lp.

A pity that we can't look at the source for /usr/lib/lpsched, so
we could see what it tests for to cause it to exit as this does.

> #/usr/lib/lpsched
> # ls -l
> total 31
> -rw------- 1 lp other 3 Mar 6 15:35 FIFO
> -r--r--r-- 1 lp other 4 Mar 6 15:35 OUTQLOCK
> -r--r--r-- 1 lp other 4 Mar 6 15:35 SCHEDLOCK
> -rw-r--r-- 1 lp other 158 Mar 3 15:38 baudrates
> drwxr-xr-x 2 lp bin 80 Feb 28 17:58 class
> -rw-r--r-- 1 lp other 6 Feb 28 17:58 default
> drwxr-xr-x 2 lp bin 80 Feb 28 17:58 interface
> -rw-r--r-- 1 lp other 2889 Mar 6 15:34 log
> drwxr-xr-x 2 lp bin 80 Feb 28 17:58 member
> drwxr-xr-x 2 lp bin 144 Sep 22 08:32 model
> -rw-r--r-- 1 lp other 237 Feb 24 10:44 oldlog
> -rw-r--r-- 1 lp other 1748 Mar 6 15:35 outputq
> -rw-r--r-- 1 lp other 256 Mar 3 18:49 pstatus
> -rw-r--r-- 1 lp other 416 Feb 28 17:58 qstatus
> drwxr-xr-x 7 lp bin 128 Feb 28 17:58 request
> -rw-r--r-- 1 lp bin 5 Mar 6 15:24 seqfile

What do you get with "ls -lR" in /usr/lib/lpsched. That should
also list the files in the directories like class, interface, member,
model, and request. (Request might have queued print jobs still hanging
around in it. It might help to clean that out, too. It looks as though
it has at least five files (or subdirectories) in there, based on the
link count.