What, exactly, are you enabling?

sudo systemctl enable org.cups.cupsd.service

OK, think I see the situation. You have a printer with a print server built in, and you're trying to set your system up as a print server that just connects to the other print server?

Correct? Seems like an odd way to do it, but that's all I can figure out from what you've posted.

Edit: If so, I think this is what cups-browsed.service is for.

Not quite. I have a plain-old-printer, not a printer with a printer server. The printer is simply plugged into a networked computer. Together, the form a printer server. After turning-on the computer and printer, everyone expects to be able to "see" the printer on the network, and to be able to print to the printer - simple enough. But to work, cupsd must be running, in addition to avahi-daemon and, of course, IP.

"cups-browsed.service" is something quite different. We can see at man 8 cups-browsed:
cups-browsed has four independently switchable functions:
1. Browse Bonjour broadcasts of remote printers and create/remove local raw queues pointing to these printers.
2. Browse CUPS broadcasts of remote printers and create/remove local raw queues pointing to these printers.
3. Browse an LDAP server for printers and create/remove local raw queues pointing to these printers.
4. Broadcast local queues with the CUPS protocol.

The "print server" has no need of "browsing" for other network printers, and also, there will be no broadcasting the obsolescent CUPS protocol. So, there is no need to run cups-browsed at all.

Now, *if* somebody *did* have a reason to run cups-browsed, then we can see in /usr/lib/systemd/system/cups-browsed.service:

[Unit]
Requires=org.cups.cupsd.service
[Install]
WantedBy=multi-user.target

And then, the administrator might fail to notice that they got org.cups.cupsd.service gratuitously.

Enabling/Installing cups-browsed.service just to get org.cups.cupsd.service to run is the wrong way to do things.

If the printer is plugged directly into the Arch system, you should be hitting printer.target and the cupsd service would be started.

I'm not seeing that. Please, what might "activate" printer.target? "systemd-analyze dot" shows nothing that would activate printer.target. Was there something in udev that was suppose to do this?

$ grep printer.target /usr/lib/udev/rules.d/*
/usr/lib/udev/rules.d/99-systemd.rules:SUBSYSTEM=="printer", TAG+="systemd", ENV{SYSTEMD_WANTS}+="printer.target"
/usr/lib/udev/rules.d/99-systemd.rules:SUBSYSTEM=="usb", KERNEL=="lp*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="printer.target"
/usr/lib/udev/rules.d/99-systemd.rules:SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="printer.target"

Certainly SUBSYSTEM=="usb" will not find the parallel port. What is going on with SUBSYSTEM=="printer"?

$ systemctl status printer.target
● printer.target - Printer
Loaded: loaded (/usr/lib/systemd/system/printer.target; static; vendor preset: disabled)
Active: inactive (dead)
Docs: man:systemd.special(7)

$ dmesg|less
...
[ 11.781330] PCI parallel port detected: 1407:8000, I/O at 0x9c00(0x0), IRQ 22
[ 11.781362] parport0: PC-style at 0x9c00, irq 22 [PCSPP,TRISTATE,EPP]
[ 11.788021] parport0: Printer, Hewlett-Packard HP LaserJet 6MP
...

man 7 systemd.special
printer.target
This target is started automatically as soon as a printer is plugged in or becomes available at boot.


$ udevadm info /dev/parport0
P: /devices/pci0000:00/0000:00:1e.0/0000:01:01.0/ppdev/parport0
N: parport0
E: DEVNAME=/dev/parport0
E: DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:01:01.0/ppdev/parport0
E: MAJOR=99
E: MINOR=0
E: SUBSYSTEM=ppdev

Well, there, "SUBSYSTEM=ppdev" is different from "SUBSYSTEM=printer".

$ pacman -Qo /usr/lib/udev/rules.d/99-systemd.rules
/usr/lib/udev/rules.d/99-systemd.rules is owned by systemd 232-3

The argument could be made that this is a "systemd" package problem...

Supposing that only "printers" are plugged into the parallel port, there could be a rule added to /usr/lib/udev/rules.d/99-systemd.rules:

SUBSYSTEM=="ppdev", TAG+="systemd", ENV{SYSTEMD_WANTS}+="printer.target"

$ grep ppdev /usr/lib/udev/rules.d/*
/usr/lib/udev/rules.d/50-udev-default.rules:SUBSYSTEM=="ppdev", GROUP="lp"
/usr/lib/udev/rules.d/56-hpmud.rules:SUBSYSTEM=="ppdev", OWNER="root", GROUP="lp", MODE="0664"
/usr/lib/udev/rules.d/80-drivers.rules:SUBSYSTEM=="module", KERNEL=="parport_pc", RUN{builtin}+="kmod load ppdev"

Is that preferable?

Ah, so systemd doesn't account for parallel printers. Yes, that's a systemd problem, not a CUPS problem.

Does parport even support hotplug? Do you get kernel/udev events when you plug it in?

Hmm - unplugging and plugging the printer cable does not show any response from "udevadm monitor". I suppose that unloading and loading the parport module would register an event, but that is a different thing. It may be that the parport stack - parport_pc ppdev parport - only concerns itself with the physical interface, and not with what is plugged there.

UDEV [128204.607345] add /devices/parport0 (parport)
UDEV [128204.655510] add /devices/pci0000:00/0000:00:1e.0/0000:01:01.0/ppdev/parport0 (ppdev)

$ udevadm info /sys/devices/parport0
P: /devices/parport0
E: DEVPATH=/devices/parport0
E: DEVTYPE=parport
E: SUBSYSTEM=parport

$ udevadm info /sys/class/ppdev/parport0
P: /devices/pci0000:00/0000:00:1e.0/0000:01:01.0/ppdev/parport0
N: parport0
E: DEVNAME=/dev/parport0
E: DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:01:01.0/ppdev/parport0
E: MAJOR=99
E: MINOR=0
E: SUBSYSTEM=ppdev


Unloading and loading parport_pc is what actually generates the dmesg entry:
[128204.483424] PCI parallel port detected: 1407:8000, I/O at 0x9c00(0x0), IRQ 22
[128204.483464] parport0: PC-style at 0x9c00, irq 22 [PCSPP,TRISTATE,EPP]
[128204.489966] parport0: Printer, Hewlett-Packard HP LaserJet 6MP

Clearly, parport_pc knows about the attached printer, but the printer itself is not a "udev event". Without additional heuristic mechanisms, for the moment, I'm guessing that the "ppdev" and "parport" subsystem events are the only clues for udev.

Another approach is to add an org.cups.cupsd.service Install dependency on the "parport0" device:

WantedBy = sys-subsystem-ppdev-devices-parport0.device
or
WantedBy = sys-subsystem-ppdev-devices-%i.device

*and also* to add another udev rule for /usr/lib/udev/rules.d/99-systemd.rules:

SUBSYSTEM=="ppdev", TAG+="systemd", ENV{SYSTEMD_ALIAS}+="/sys/subsystem/ppdev/devices/$name"

That would be a little more nuanced than WantedBy= printer.target default.target, since cupsd would then only be started when a specific parallel port existed and was active. Still, what, if anything, might be plugged into that parallel port would be another matter.

There is still also /usr/lib/systemd/system/org.cups.cupsd.socket:
[Unit]
Description=CUPS Scheduler
[Socket]
ListenStream=/run/cups/cups.sock
[Install]
WantedBy=sockets.target

And parport_pc could access cups.sock when it finds an actual printer attached, which would then start cupsd. That would require some systemd *and* cupsd sympathy from the parport_pc authors:

$ modinfo parport_pc
...
author: Phil Blundell, Tim Waugh, others

Tim Waugh <twaugh@redhat.com>

Of course, another approach would be to write a "parallel port printer monitor daemon", to poll the parallel port, and then start cupsd.

For instance, /proc/sys/dev/parport/parport0/autoprobe:

CLASS:PRINTER;
MODEL:HP LaserJet 6MP;
MANUFACTURER:Hewlett-Packard;
DESCRIPTION:Hewlett-Packard LaserJet 6MP Printer;
COMMAND SET:PJL,MLC,PCLXL,PCL,POSTSCRIPT;

But - if the printer is not attached when the parport_pc module is loaded, then there will be nothing to find in /proc/sys/dev/parport/parport0/autoprobe. So polling seems to be required.

For the moment, it is easier to just start cupsd on boot, when cupsd has been "enabled/installed".

Right, so this all seems to be working as designed.