avahi-daemon - where?

When I run:

locate avahi | grep .conf

on this Ubuntu (therefore Debian so quite Minty) box I find:

/etc/avahi/avahi-daemon.conf /etc/dbus-1/system.d/avahi-dbus.conf /etc/init/avahi-cups-reload.conf /etc/init/avahi-daemon.conf /etc/resolvconf/update-libc.d/avahi-daemon /usr/share/man/man5/avahi-daemon.conf.5.gz /usr/share/upstart/sessions/unicast-local-avahi.conf /var/lib/dpkg/info/avahi-autoipd.conffiles /var/lib/dpkg/info/avahi-daemon.conffiles

The first few of those might be a good place to start reading/tweaking.

More generally "locate" is good for quick returns on simple searches for filenames, because it's just searching a database (which has to be built, then usually updated in the background as a system job). That's obviously less useful for files created since the last update.

On the other hand "find" lets you craft intricate search patterns, and manipulate the resulting files as part of the search process, but runs slower as it has to actually traverse the filesystem rather than perform a database lookup.

Any chance something in your code is in a tight loop ?

There might also be some toys to play with.

Paul

Thanks for that. My app is a Xojo app, but I think the problem is wider than that, see:

I use Catfish file search, which is in the Mint repo. It found 15 entries for "avahi-daemon" in about 5 seconds as it keeps an index. All were in /etc/.

It always defaults to your home folder, but a drop-down arrow allows you to change that to "file-system".

Your app should not be writing to the printer. Your app should be writing to the linux printer system and that should be writing to the printer

You dont need to stop avahi, just stop the print system using it.

- Put the printer on a fixed IP address

- tell it to use ONLY HP JetDirect on IIRC port 9100. Switch of all 'bonjours' and smart crap completely. It's for numpties who cant configure a network. You can.

- set up a printer on the Linux - not the application - using that fixed iP address Port and protocol - give it a name like RAWPRINTER

- test it THEN go back to the application and select RAWPRINTER no matter how many other options it gives you.

I had humongous problems on my print software with multiple different printers being offered till I realised none of them were either helpful or needed so I disabled everything on the printer using its web interface...

Pv4: Enabled IPv6: Enabled DHCP: Disabled BOOTP: Enabled AUTOIP: Disabled TFTP Configuration File: Disabled Telnet configuration: Disabled DHCPv6: Enabled LPD Printing: Disabled LPD Banner Page Printing: Disabled FTP Printing: Disabled

That's what worked for me Looking at it I could probably bin BOOTP, IPV6. DHCPV6, and probably IPP and IPPS, but they works as well as 9100 printing

In particular air print and bonjour you really dont need or want unless you have apple kit trying to use the system

disabling it should be something like

sudo systemctl disable avahi-daemon.service

it may or may not not fix your problem, but it is easy to reverse.

Didn't help. I've therefore tried both the fixes suggested in that StackExchange post, to no avail.

I expect it'll be doing whatever is appropriate for Linux. The same code prints OK under macOS and, AFAIK, Windows. What the code compiles to and what library calls get used, I know not.

But as a user, it's not my business to organise that. I wouldn't even know how to.

You mean as opposed to a DHCP address provided by the router?

What does this HP stuff have to do with a Canon G9050 printer?

I am. I have, and I can see it.

I'm not. There's no way, these days, to "set up a printer" inside an application. All you can do is to use Page Setup to define paper size etc and Print to set params like duplex, number of copies, which pages to print, etc. It's been like that for yonks (always was under macOS, Windows eventually caught up).

I can go to the Mint Start Menu (or whatever it's called) and select Control Centre and then Printers (under Administration). I see my printer there and can select it and print a test page to it from that panel. Under the app, however, I can click the Print button, and the Print pane appears, but around

G6050 sorry.

Xojo is compiled or interpreted. The interpreted version is XojoScript or something. Debugging the script version could be hard or easy, depending on their level of support.

It compiles and links to ELF, using LLVM and lld linker.

file xojo_executable # Taste test

ELF blah blah blah

ldd xojo_executable # See what libraries link in. Not important, # but is part of learning your new ecosystem.

Debuggers are generally an animal of their ecosystem. In Windows for example...

compile with gcc, debug with gdb compile with Visual Studio, debug with windbg

While both Windows toolflows nominally make PE or PE+ executables (a standard like an ELF), the inner details take a separate debugger for each. Windbg for example, on a crash, has a single command which dumps a stack trace and points out the culprit to some extent. That one command (for a guy like me), is all that's needed. Unless you plan on single stepping the code, setting breakpoints, there is little to know to get some amount of detail from an object code crash.

See if your Xojo documentation mentions "lldb", a debugger. If you are compiling to native code, you should be able to attach to the running process.

In one terminal:

./xojo_executable

In a second terminal:

ps aguwwwx | grep xojo_executable # We want to know the Process ID or PID number 1234

# Now this part is rank speculation on my part. # The launch will be something like this...

lldb -p 1234 # Attach debugger to running xojo_executable

Since we know your application is stable until you print, there is no need for lldb to launch the executable. If it crashed at launch (50 milliseconds afterwards), then you would need to learn how to launch an ELF with lldb.

man lldb

Now, try and Print in xojo_executable GUI. Let's crash this pig.

The crash should now "trip" the attached debugger. Instead of some error dialog appearing, the lldb will have some lines of stuff printed. Then, you will need to issue the stack-trace-like command, which tells you what routine(s) were on the stack at crash time.

For journeyman programmers, we don't need to know how anything works. We start with breadcrumbs, taking the stuff from the stack dump, and... Googling :-) If the same line of print code has crashed for someone else, Googling it may yield a forum entry.

Paul

The print pane only doesn't vanish if the printer is powered off at the time I select it. But this kind of defeats the object.

I don't use any XojoScript, haven't looked into it, so I don't know under what circs I might want to. My stuff is all compiled. The source-level debugger is built into the IDE. You can run under it locally or run to a remote host. I tend to develop under macOS and to have Lin/Win running in VMs (VirtualBox under Mojave) and remote-debug to the VMs for testing non-macOS versions (except the PI, I have real hardware for that).

Yes.

It doesn't, which is unsurprising. I imagine the Xojo devs may use it, but for those of us who use Xojo, the source-level debugger normally suffices.

OK. lldb appears to stop all threads in my app (none of which I recognise), so I type continue and on it goes. Trying to print gives a SIGABRT in raise.c:51:1, which may mean something to the Xojo devs. I'll try a bit more tomorrow. Thanks for the pointer.

I could find little of value in Google.

One hint, is that a Xojo window could be closed by the programmer, before the thread in the window was properly disposed of. The thread tries to do IO and crashes. And a ListBox may be involved.

But that's not your bug exactly, and is hardly breadcrumb material.

So maybe when you Print, a window tries to open, the calling code to make the window exits due to some trivial issue (in a normal program would have gone away quietly), a thread for the window is still running and not disposed of properly.

Paul

HP JetDirect is most widely known to accept print streams on TCP/9100, but HP didn't invent it, most manufacturers support it, anything not out of the ark will accept IPP on TCP/631

"home" printers may stop there, but "business" printers have swathes of other protocols, LPR on TCP/515, and probably appletalk, IPX and IBM mainframe DLC still exist as far as printers are concerned. Unless you disable what you don't use, printers are about the most "chatty" things on most networks

Thanks, that's useful to know. Trouble is that unless you know, it appears (with the name it has) to be proprietary and limited to HP printers so one ignores it and tries something else.

yiu may be offered moire than one instance of the saem printerprinter

Yes.

Port 9100 was started by HPs jet direct, but nearly all printers now support it.

I am saying remove all alternative network print method from the PRINTER. My experience has been that printers on ANY network work best if:

- They have fixed IP addresses.

- They have the minimum number of possible communication protocols running

- You have the exactly correct printer driver installed.

The two most reliable protocols I have found are 9100 and IPP.

Actually I though HP DID invent it.

Otherwise I totally agree.

Yes, and I had two instances of my printer appearing on my linux box when either bonjour or airport were enabled

Even on my pukkah HP printer it now appears to be called '9100' Sorry to have confused you, but that is what we called it back in the day