search

michaelrsweet / pappl

PAPPL - Printer Application Framework
https://www.msweet.org/pappl
Apache License 2.0
309 stars 49 forks source link

USB printer gets lost after shutdown and restart #92

Closed tillkamppeter closed 3 years ago

tillkamppeter commented 3 years ago

Describe the bug In the PostScript Printer Application I create a USB printer, does not matter whether via the web interface or whether via the "autoadd" sub-command. I can check by the web interface or by looking into the state file that the printer got actually created. I shut down the Printer Application and start it again. Now the printer is not there any more, and the DNS-SD name of the system has turned into the name of the now gone printer. Also with a look into the state file I can see that the printer has disappeared. Looking into the state file between the two sessions shows that the printer is still there and the DNS-SD name of the system still intact, so it seems that the bug is in the loading of the state file when the Printer Application starts. The problem only occurs with USB print queues for my HP OfficeJet Pro 8730 and not with network print queues. In the USB case the device ID of the printer is very long but it is shorter for the network cases, probably the long device ID makes a buffer overflow, causing a mess when loading the state file.

To Reproduce You need the PostScript Printer Application and a printer with a long USB device ID, modern HP inkjets do well here. If you do not have such a printer try to temporarily modeify PAPPL's code to artificially generate the device ID for DNS-SD printers so that it gets unnaturally long and use the DNS-SD entry of the discovered printers. Or simply only reproduce the second session, starting the PostScript Printer Application with my attached state file of after shutting down the first session.

Steps to reproduce the behavior: (Optional) First session creating a USB print queue Run the command

$ PPD_PATHS=/path/to/your/ppds ps-printer-app -o log-level=debug server > log1 2>&1

to fire up the server, then, with a USB printer connected and turned on, run

$ ps-printer-app autoadd

to add the printer, verify by looking into the state file or into the web interface. Terminate the first session via

$ killall ps-printer-app

You see in the state file now that the printer got correctly saved, so it should re-appear in the next session.

Second session to see that the printer is gone If you did not do the first session, copy the attached state file of after terminating the first session:

$ cp ps_printer_app.state.after-shutdown-1.txt  /tmp/ps_printer_app.state

and start the second session

$ PPD_PATHS=/path/to/your/ppds ps-printer-app -o log-level=debug server > log2 2>&1

and see in the web interface and in the state file that the printer is gone, but to remember you of the good times with it, the DNS-SD name of the system has turned into the printer's name.

Expected behavior Every printer you create stays conserved in the next sessions.

Additional context

michaelrsweet commented 3 years ago

@tillkamppeter It looks like the "#" characters in the device ID are causing the problem... I have a potential solution and will post results later today...

michaelrsweet commented 3 years ago

@tillkamppeter This change seems to work for me...

[master fc19d84] Fix papplSystemLoadState for printers whose device IDs contained the '#' character (Issue #92)

tillkamppeter commented 3 years ago

Thanks, your fix seems to principally work, but is not perfect. The first session saves the head line of the printer entry as follows:

<Printer did="MFG:HP;MDL:HP OfficeJet Pro 8730;CMD:PCL5c,PCLXL,POSTSCRIPT,NATIVEOFFICE,PDF,PCL3GUI,PCL3,PJL,Automatic,JPEG,PCLM,AppleRaster,PWGRaster,802.11,802.3,DESKJET,DYN;CLS:PRINTER;DES:D9L20A;CID:HPIJVIPAV9;LEDMDIS:USB#FF#CC#00,USB#FF#04#01;MCT:MF;MCL:DI;MCV:3.0;SN:CN783F60W1;S:038080C484100001005800800004418001e4518001e4618001441180014;Z:05000009000009000009000009000009,12000,17000000000000000000000000000000,181;" driver="auto" id="1" name="HP OfficeJet Pro 8730 (USB)" uri="usb://HP/HP%20OfficeJet%20Pro%208730?serial=CN783F60W1">

The second session loads the state file and so re-creates the printer entry, which shows in the web interface, but the second session does not remove the closing > from the line, making it part of the URI, which one sees in the state file saved by the second session:

<Printer did="MFG:HP;MDL:HP OfficeJet Pro 8730;CMD:PCL5c,PCLXL,POSTSCRIPT,NATIVEOFFICE,PDF,PCL3GUI,PCL3,PJL,Automatic,JPEG,PCLM,AppleRaster,PWGRaster,802.11,802.3,DESKJET,DYN;CLS:PRINTER;DES:D9L20A;CID:HPIJVIPAV9;LEDMDIS:USB#FF#CC#00,USB#FF#04#01;MCT:MF;MCL:DI;MCV:3.0;SN:CN783F60W1;S:038080C484100001005800800004418001e4518001e4618001441180014;Z:05000009000009000009000009000009,12000,17000000000000000000000000000000,181;" driver="auto" id="1" name="HP OfficeJet Pro 8730 (USB)" uri="usb://HP/HP%20OfficeJet%20Pro%208730?serial=CN783F60W1>">

I did not try, but probably the > will echo ad infinitum in subsequent sessions.

tillkamppeter commented 3 years ago

Note that this will probably happen in other <ITEM param=value ...> ... </ITEM> structures in the state file as well.

michaelrsweet commented 3 years ago

Ah, yes. Working on that now...

michaelrsweet commented 3 years ago

I ended up writing a simpler version of cupsFileGetConf for PAPPL, one that doesn't support '#' comments (which is the source of this bug...)

[master 6982c8b] One more change for papplSystemLoadState bug - strip trailing ">" from "<something value(s)>". Easiest fix was to provide a local implementation of cupsFileGetConf that doesn't support comments (Issue #92)

tillkamppeter commented 3 years ago

Now it works. Thank you very much.