Calling Printer Application with "autoadd" segfaults #89
Comments
|
@tillkamppeter Can you retry this with the current Github master code? And enable debugging (--enable-debug) so that you can get a backtrace if there is a crash? |
|
I have investigated the case now and observed the following: If I add a printer manually via the web interface and select "Auto Detect" in the driver menu, the server calls If I have a server running and I want to automatically add all supported printers using the "autoadd" sub-command, I have a second instance of the Printer Application running, the one I fired up with the sub-command. This one works as a client for my server, sending IPP commands to make the server create a print queue. In this case the decision about which driver to use is made by the client calling So there are two possibilities to fix the bug:
I recommend (2), as
|
michaelrsweet
added
bug
|
@tillkamppeter Option 2 is probably the right answer. I'll have a fix sometime today... |
…oop` (Issue #89) Also fix an implementation bug - was looking printers up by their device IDs and not by their URIs.
|
I have built your GIT master and also added a crash guard to No printer got created and the server has logged the following: The printer is again the HP OfficeJet Pro 8730, connected via both USB and network. are most probably not the culprit, I get them on every device auto-discovery run of a Printer Application but the device ID is always correctly read out or synthesized. |
|
@tillkamppeter Looks like the device URI schemes weren't registered yet... [master 39c81ff] Make sure standard URI schemes are added (Issue #89) |
|
Thanks. We are coming closer. Now printers get actually auto-generated, but for my one single printer I get three queues, for the three ways it got autodetected: DNS-SD, SNMP, and USB. You should add some mechanism to detect whether various auto-discovery entries come from the same physical device. Best way is the UUID in the printer hardware. I do not know ehether you can obtain it on all 3 auto-discovery methods, for network you can also check IP address, host name, and perhaps even MAC address. Also the printer's serial number is a candidate. I suggest priorities between auto-discovery/connection types, for example USB has highest priority, as it is most secure and if someone connects a printer by both USB and network it can be more than belt and suspenders, perhaps the higher security of USB for the local user but also sharing the device on the network. After that I would suggest DNS-SD, as it is more sophisticated than SNMP, or perhaps also give the user a possibility to configure. |
|
@tillkamppeter There is absolutely no way for us to detect duplicate network printers (between the different protocols) short of resolving the addresses which will wake the printers up. My solution will be simple: only auto-add USB printers. Network printers MUST be added manually (or you can provide your own autoadd-network command and deal with the consequences yourself...) |
|
So let us do as follows then: For USB, while the Printer Application is running, we let it somehow use UDEV or so to auto-detect when there is a USB printer connected and if so but no queue for this printer is already there, create it. If a queue is there enable the queue on appearing and disable (but not remove) on disappearing of the printer. This is probably all what PR #36 is about. So also newly connected USB printers get automatically set up when the Printer Application is alreasy running. The "autoadd" subcommand can stay as it is and output a warning on the terminal if it has set up more than one printer, telling the user to visit the web interface and remove the unwished ones. Anyway, the command should always tell the user on the terminal how many printers it has set up. Important is for developers of Printer Application Snaps to not call it automatically after firing up the server. The Printer Application running as server should have PR #36 implemented and so automatically set up USB printers. |
|
@tillkamppeter Any long-term monitoring/auto-add/auto-pause/auto-resume functionality needs to be managed separately, and honestly since the snap hotplug functionality is still non-existent I'm not in a hurry to add it. This is not something that all printer applications will have enabled by default. |
|
Hotplug inside Snaps is possible. I will look for some sample code. |
|
@tillkamppeter Note that I'm still tracking the hot-plug functionality via PR #36, and my goal is to support both USB and DNS-SD. |
Describe the bug
I am running the PostScript Printer Application as server. While it is running I run the command:
to automatically detect and add printers. The program makes the server logging the lines shown below and then segfaults. I get the same independent whether I have already set up a printer or not.
No
corefile got written.Additional context
Log entries of the server in debug mode:
The text was updated successfully, but these errors were encountered: