desktop-packages team mailing list archive

[Till Kamppeter <1509423@xxxxxxxxxxxxxxxxxx>]

** Changed in: canonical-devices-system-image
       Status: Confirmed => Invalid

** Changed in: cups (Ubuntu)
       Status: New => Triaged

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1509423

Title:
  cupsd on the phone is unable to run sub processes, they all cause
  "Command not found"

Status in Canonical System Image:
  Invalid
Status in cups package in Ubuntu:
  Triaged

Bug description:
  I have started to test the printing stack of Ubuntu on the phone.

  I have a Nexus 4 now to test the printing stack on the phone.

  First I have updated the USB-connected phone to the development branch
  of the OS via

  ubuntu-device-flash touch --channel=devel

  with the phone booted into Ubuntu and the screen unlocked.

  After the reboot of the phone I have run

  phablet-config writable-image

  to be able to install packages with apt-get and entered a shell on the
  phone via

  phablet-shell

  In the shell I first installed a level-1 printing stack (See
  https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-
  stack-with-mobile-in-mind for the levels):

  sudo apt-get install cups-daemon cups-browsed avahi-daemon

  This makes the following new packages getting installed:

  The following NEW packages will be installed:
    avahi-daemon bc bind9-host cups-browsed cups-daemon libavahi-core7
    libavahi-glib1 libbind9-90 libcupsmime1 libdaemon0 libdns100 libgeoip1
    libisc95 libisccc90 libisccfg90 liblwres90 libpaper1 ssl-cert
  0 upgraded, 18 newly installed, 0 to remove and 0 not upgraded.
  Need to get 1,502 kB of archives.
  After this operation, 4,698 kB of additional disk space will be used.

  The installation was hanging on the postinst of CUPS, so I had to open
  a new shell in another terminal and kill the postinst for the
  installation process to finish.

  sudo apt-get install -f

  has re-run the CUPS postinst and this time it finished.

  As the phone apps do not yet have a print dialog I needed a print
  client on the phone, and also some tools for developing and debugging.
  So I have installed cups-client, giving me command line printing and
  print admin commands, as lp, lpstat, lpinfo, lpadmin, ...:

  sudo apt-get install cups-client
  [...]
  The following NEW packages will be installed:
    cups-client cups-common libcupsfilters1 libcupsimage2
  0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
  Need to get 368 kB of archives.
  After this operation, 2,810 kB of additional disk space will be used.

  PID 1 on the phone is still Upstart, Upstart is configured to start
  CUPS on-demand, via

  /etc/init/cups.override

  cups.override needs to be corrected, as cupsd does not support the
  "-x" option any more, so I have removed the "-x 30" from the cupsd
  command line. Now cupsd starts when running commands like

  lpstat -r
  lpstat -v
  ...

  After that I did

  sudo start cups-browsed

  to start cups-browsed to get the queues from remote CUPS servers
  locally available (level 1 printing stack).

  lpstat -v

  shows my printers shared on remote CUPS servers now.

  Note that CUPS admin tasks need "sudo" as the "phablet" user is not in
  the "lpadmin" group.

  For the printing tests I do the CUPS logging (in
  /var/log/cups/error_log) in debug mode, running

  sudo cupsctl --debug-logging

  sudo cupsctl

  shows my settings.

  Now I print via

  lp -d printer ~/.bashrc

  CUPS is now supposed to send the job via IPP (Internet Printing
  Protocol) to the remote CUPS server where the printer is actually
  connected to. This it does using a backend, a small helper program, in
  our case /usr/lib/cups/backend/ipps.

  Printing does not work yet:

  1. CUPS reports exit status 127 on the ipps backend call ("command not
  found", the fact that in error_log you see "file too large" is a CUPS
  bug, exit status 127 is "command not found"), but the backend is
  called with its full path, the backend is actually present and
  executable, no libs missing (checked with "ldd"), the backend works
  directly called from the command line.

  2. No name resolution in the local network (avahi problem? avahi-
  daemon is running). Manual call of the backend only works if the host
  name in the device URI is replaced by the corresponding IP address.

  So following command prints:

  DEVICE_URI=ipps://192.168.0.11:631/printers/printer
  CONTENT_TYPE=text/plain /usr/lib/cups/backend/ipps 1 1 1 1 ""
  ~/.bashrc

  Also

  sudo DEVICE_URI=ipps://192.168.0.11:631/printers/printer
  CONTENT_TYPE=text/plain /usr/lib/cups/backend/ipps 1 1 1 1 ""
  ~/.bashrc

  prints.

  To overcome the host name resolution problem I have modified cups-
  browsed to create the local queues with IP addresses instead of host
  names in the device URIs. So the remeining problem is (1), for which I
  have opened this bug report.

  The problem is most probably no caused by AppArmor, as I do not see
  appropriate "audit" messages in /var/log/syslog and I have done

  aa-complain cupsd

  to have cupsd in complain mode and not in enforce mode.

  As both the ipp/ipps backend and another backend which is a shell
  script do not start and give exit status 127, it seems for me that
  make cupsd running a command line "strace ipp ..." will also end up in
  nothing being executed.

  So I tried

  strace cupsd -f > log 2>&1 &

  and afterwards ran a job

  lp -d canon-colour .bashrc

  After some time I canceled the job (as it did not get executed due to
  the known problem) and stopped CUPS.

  The resulting file "log" is attached. The problem happened on
  14/Oct/2015:14:55:31, you can search for "14/Oct/2015:14:55:31" in the
  log, then for "backend/ipp".

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1509423/+subscriptions