[reopened] remote printing is annoying


I’ve installed Netrunner 16 on the PC of my wife and on my PC. We’ve the same trouble with remote printing.

The situation
NAS with ip and hostname “taschenmaus”
System: Debian Jessie
Printing: cups + turboprint
Standard Printer: tp0

PC of my wife with ip and hostname “gerbil”
System: fresh Netrunner 16
I can see remote printer status “idle” with webinterface localhost:631
NAS is known in /etc/hosts
Remote Printing often fails, the remote turboprint shows status “sleep”
In firefox I see status “connecting” and then “printer is not ready”

During next reboot process of Netrunner the remote printer suddenly starts and finishes the jobs. This is reproducible.

On my PC I’ve the same behavior with Netrunner 16. It seems, that the sleeping printer get no impulse when starting a print job. Only a reboot give remote printer impulse to get ready and print stuff.

With an installed siduction, based on Debian unstable, remote printing still works without any trouble.

Sorry, but this is annoying. Such simple things like remote printing in a Lan with Linux only systems have simply to work.

How can I fix this? Without solid remote printing Netrunner unfortunately is quite useless for us, because all printers are managed with cups + turboprint on our NAS.

Kind regards,

Is the printer queue maybe set to hold ?
Can you check this on localhost:631

It is a little bit crazy. When I start my PC with Netrunner I can print on remote printer. If I start then PC of my wife with Netrunner - my PC is still running - and try to print, it fails. But when I do a

systemctl restart cups 

on PC of my wife, the remote printer do the job.

Doing reverted it is the same. Starting PC of my wife first, everything is fine with remote printing. Starting my Netrunner then - the PC of my wife is still running - cups of my PC seems be blocked. After restart cups, the job starts on remote printer.

Kind regards,

Whats that?

Sounds like a permission problem.

Hi @leszek,

sorry for making noise.

It seems, that turboprint is the culprit. When starting my PC with Netrunner 16, I’ve configured remote turboprint-monitor to start automatically when starting kf5 session (ssh -X taschernmaus turboprint-monitor).

If starting PC of my wife with kf5, remote turboprint-monitor also starts with ssh -X command. But obviously turboprint does not like to be started twice. So one instance of turboprint-monitor blockes the other. The local cups system on the client with blocked printing holds the jobs and the reboot solves the blockage and gives hold jobs free for remote printer.

I’ve removed turboprint stuff from my NAS, have configured NAS printer with original brother driver and the cups trouble has gone, remote printing works like a charm now :slight_smile:

So this trouble had not to do with Netrunner 16, I apologise.

Kind regards,

I am glad you found the culprit and was able to solve this issue


sorry, but I’ve to reopen the thread, after some tests I’ve the same issues even without turboprint.

Strange to say this issues don’t occur when printing without started x Session. When I don’t start kf5 or icewm on Netrunner 16, logged in on bash prompt on both machines, then I can print a lot of jobs variantly from both machines without blockage, for example

ls -la|lp -d lp0

So I think it has not to do with printer configuration on my NAS.

But when starting kf5 or icewm, opening okular or claws-mail and try to print, then it could be, that on of machines is blocked for printing after executing some print jobs on remote printer. Then only a reboot or a

systemctl restart cups

of Netrunner 16 give jobs free for printing.

Where can I estimate to fix this?

Apart from that I’ll prepare two machines with Debian Jessie for testing and will give further feedback.

Kind regards,


one question: Is it possible downgrading to cups 1.7.5 on Netrunner 16?

I remember of some issues with cups 2.0.x on Manjaro a few months ago. After downgrading to 1.7.5 this issues had gone. Perhaps it helps also in this case.

cups on NAS with Debian Jessie is version 1.7.5.

Apart from that I don’t like new cups stuff. With older versions < 2.x I’ve a german localised cups webfrontend. With new 2.x it seems that only english is possible.

Kind regards,

I don’t think it is possible but you can try by searching for the older version on packages.ubuntu.com. Though that package would then be made for an older ubuntu version so not sure if this will work.


I need further help, I’ve made different tests and the result:

When online at once with different clients, which have cups 1.7.5 like siduction, Debian and a Manjaro with downgraded cups, everything works fine, I can start different printing jobs on those clients and the remote printer execute this jobs fast without any trouble.

But if starting additionally a Netrunner16 with cups 2.0.2 I get above described trouble with printing. It seems, that browsing mechanism of cups 2.0.2 disturbs the other clients and strange to say this happens only when printing via x applications.

The hint to add

BrowsePoll IP-of-Printserver:631/version=1.7.5

in /etc/cups/cups-browsed does not help.

My questions: Is there a smart way to add an ubuntu source with old cups stuff and handle the cups downgrade with apt? There are a lot of cups packages installed and it would be painful to download and install that stuff manually.

I have found this:

Which is the correct entry in /etc/apt/sources.list to get that cups stuff?

Kind regards,


installing old cups stuff does not work. I’ve download manually the required packages in version 1.7.5, apart from package cups the rest is installable. cups 1.7.5 is not installable because of dpkg version in actual Netrunner16, sorry but why is it not possible to install older cups package with actual dpkg?

In arch based distributions now also cups 2.0.2 is the actual version, but a simple

pacman -S downgrade && downgrade cups libcups lib32-libcups 

gives me a choise between cups 2.0.2, 2.0.1, 2.0.0, 1.7.5, 1.7.4 …

Sorry to say but for my needs like proper remote printing linux systems, which ship actual cups stuff in version 2.0 without a possibility to downgrade are not usable. Clients with cups 2.0.2 disturb clients with older cups stuff, hints like

BrowsePoll IP-of-Printserver:631/version=1.7.5

don’t help, and I don’t want to spent more time to make basic things like remote printing work properly.

Perhaps I’ll install Netrunner16 on PC of my father, he has no network, only a stand-alone PC with foto printer and I belive he’ll be satisfied with it.

Kind regards,

Did you by chance install both computer that are running Netrunner with the same host name?

Hi @AJSlye,

thanks for trying to help and you’re right, if having some machines it could be happen inadvertently giving two systems same IP. But here it is not the case :slight_smile:

The culprit seems to be cups 2.0x, here you can find an explaination what could happen having different versions in a Network, sorry, I don’t find an english version:

But here they speak about two different versions of cups 1.x, with a mixture of 1.x and 2.x that hint does not help anymore.

I can avoid this issue with booting cups 1.7 only clients (manjaro with downgraded cups, Debian Jessie or siduction. I can print then from all clients without any problems, but when starting a further client with cups 2.0.x, then shit happens :slight_smile:

And if cups 2.0 is not downgradeable on a client, then I’ve some possibilities:
Using annother distribution on Server with cups 2 or
Using another distribution on client where it is possible to install an older cups version or
arrange with that issue

But giving up Debian stable on server? That is not an option for me and I also don’t like to limit my needs here and I think, that needs, having remote printing without any issues, are not extraordinary.

To point out, I like Netrunner16, the teamwork between your developers and people arround kf5, the artwork and having a well configured desktop with it and my plan is to install it on PC of my father.

But in my Network unfortunately I’ve to replace Netrunner with a distribution, where I can have an older version of cups.

I’ve downloaded manjaro-kde-0.8.13-rc2-x86_64 and I’ll give it a try. But to make clear: If you offer an actual iso of rolling branch based on manjaro / arch, then I’ll tested it, because I like actual kde stuff, rolling releases and nice artworks :slight_smile: and I’m sure, I’ll get these things with rolling netrunner branch. But please, please, adapt the downgrade feature of arch based distributions, I’ve mentioned above, so that there is a possibility for me to get an older cups version.

I’ve seen you are an active member of english manjaro forum. Perhaps we will read of each other there.

Kind regards,

Our Rolling Edition is alread based on Manjaro 0.8.10, the current ISO is quite old though, there are a few hoops to jump through to get it up-to-date.