2 Replies Latest reply on May 7, 2015 12:33 PM by Rachel Peters

    Mac Queue Pausing in Yosemite

    Rachel Peters Wayfarer

      Hi, all,


      We've run into a really interesting problem lately and I would love any help anyone has with this issues. On our campus, we use a custom script to add our two print queues to some public access iMac stations in our library. Because the stations must allow guest access as well as the ability to print, we have a shortcut to our script that allows anyone using the station to add the queues tied to their username.


      Lately, we've been seeing an issue in which suddenly the print queues on the iMacs will enter a paused state. They cannot be resumed manually, and will cause the paused state to persist even after the queues are removed, CUPS cleared, machines rebooted. This randomly happens to random machines, and somehow clears itself minutes to 24 hours later. Once the queue enters the paused state, jobs are no longer sent to the print server. We haven't managed to find any patterns in how this happens. It might be related to the 10.10.1 or 10.10.2 updates, but we're not sure, this is just assumption based off of the fact that OS X updates have broken things previously.


      We've been working with Pharos support but haven't figured out a solution yet.


      Here's the script:



        if printerName = "UCMGlobal" and printerName2 = "UCMColor" then

        do shell script "lpadmin -x UCMGlobal"


        do shell script "lpadmin -x UCMColor"


        do shell script "sudo chown -R root:wheel /Library/Printers"


        do shell script "sudo chown -R root:wheel /usr/libexec/cups"


        delay 1

        do shell script "sudo chmod -R 755 /Library/Printers"


        do shell script "sudo chmod -R 755 /usr/libexec/cups"


        end if

      on error

        delay 1

      end try



        set tuser to the text returned of (display dialog "Enter your UCMNet ID:" default answer "For Example: jdoe" default button 2 with title "UC Merced Campus Printer Utility")

        set pass to the text returned of (display dialog "Enter your Password:" default answer "" default button 2 with title "UC Merced Campus Printer Utility" with hidden answer)


        set tpass to do shell script "printf \"<?php echo rawurlencode('%s');?>\" " & quoted form of pass & " | php"

        set printerName to "UCMGlobal"

        set ServerName to "ucmprint.ucmerced.edu/ucmglobal?waitjob=false"

        set printerURI to "smb://" & tuser & ":" & tpass & "@" & ServerName


        set printerName2 to "UCMColor"

        set ServerName2 to "ucmprint.ucmerced.edu/ucmcolor?waitjob=false"

        set printerURI2 to "smb://" & tuser & ":" & tpass & "@" & ServerName2


        do shell script "lpadmin -p " & quoted form of printerName & " -v " & quoted form of printerURI & " -P /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/Resources/Generic.ppd -o printer-is-shared=false -E"


        do shell script "lpadmin -p " & quoted form of printerName2 & " -v " & quoted form of printerURI2 & " -P /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/Resources/Generic.ppd -o printer-is-shared=false -E"


        display dialog "UCMGlobal added successfully!" buttons {"Ok"} default button 1 with title "UC Merced Campus Printer Utility"


      on error

        display dialog "Unable to configure UCMGlobal" buttons {"Ok"} default button 1 with title "UC Merced Campus Printer Utility"

      end try


      Here's what the CUPS logs look like during a successfully sent job:

      localhost - - [19/Mar/2015:09:22:13 -0700] "POST /printers/UCMGlobal HTTP/1.1" 200 1532 Create-Job successful-ok\

      localhost - - [19/Mar/2015:09:22:13 -0700] "POST /printers/UCMGlobal HTTP/1.1" 200 647739 Send-Document successful-ok\

      localhost - - [19/Mar/2015:09:22:18 -0700] "POST / HTTP/1.1" 200 313 Set-Job-Attributes successful-ok


      And a failed job:

      localhost - - [19/Mar/2015:10:31:02 -0700] "POST /printers/UCMColor HTTP/1.1" 200 4093 Create-Job successful-ok\

      localhost - - [19/Mar/2015:10:31:02 -0700] "POST /printers/UCMColor HTTP/1.1" 200 222001 Send-Document successful-ok\

      localhost - - [19/Mar/2015:10:31:02 -0700] "POST / HTTP/1.1" 200 347 Set-Job-Attributes successful-ok\

      localhost - - [19/Mar/2015:10:31:05 -0700] "POST / HTTP/1.1" 200 221876 CUPS-Get-Document successful-ok


      Pharos support suggested we switch from SMB to LPD. When we made that change, we encountered that the UserID for print jobs was being sent to our print server as "UserID:password". The jobs made it to the Pharos print queue successfully, but because of the password being attached to the UserID field, jobs couldn't be printed from our omegas as they weren't associated with the UserID.


      I'm really scratching my head on this one. Thanks in advance for any input!


        • Re: Mac Queue Pausing in Yosemite
          Paul LaFollette Guide


          I believe you seeing an issue not limited to Yosemite but can be duplicated on Mavericks and before (though not nearly as often).  Yosemite has somewhat "improved" security controls in place which means that while security may be "better", it is also easier to "break" as in resulting in a problem that needs worked around.


          Yosemite (and Mavericks in my experience) are more actively "aware" of the printer or print queue "status" (online, offline, error, etc.) and consequently is more likely to enter an Offline status when the OS perceives the print connection to not be available (a simple "paused" state of the printer may trigger this). 


          You're seeing Yosemite perceiving the print connection as offline or unavailable however briefly (causing the print connection to "pause").  Unfortunately, the "improved" security controls require the use of Administrative rights in order to resume (un-pause) the printer object on the Mac.


          There is a "hack" which we have used (very successfully) that will allow non-admin users to un-pause ("resume") the print connection without entering Administrative authorization.   Basically, the "hack" grants regular users authorization for elevated print management controls.




          You may choose not to do this, or may want to do a variation of this rather than grant these rights.  Without telling the users they had higher print management rights, we've not encountered any issues due to misuse of the elevated print management access.


          Check this old thread on apple's forums: https://discussions.apple.com/thread/2245382

          About half way down "John Blanchard1" posts regarding almost identical command, and they discuss variations of the command (and what the command does).  Basically, it grants users rights in the "lpadmin" group which then controls what users can (or cannot) do with the print connections.


          Hope this helps.


          - Paul L.

            • Re: Mac Queue Pausing in Yosemite
              Rachel Peters Wayfarer

              Thanks for the reply, Paul. We had granted the "guest" (I use the term lightly because it's been tweaked so much that it in no way resembles a traditional OSX guest account) admin rights for printers and it did not seem to do much to alleviate the problem. After a lot of back and forth between all of the parties involved, we found a solution in a combination of running the computers in relaxed sandboxing mode and turning off bidirectional printing. You are correct that the pausing was caused because Yosemite was querying the print queues so often that any blip in communication resulted in an error as far as Yosemite was concerned. Relaxed sandboxing mode seemed to make it so a majority of those blips were ignored by Yosemite and we didn't see paused queues. Turning off  bidirectional printing also helped to alleviate some remaining errors in which Yosemite was pause the queues if it didn't get a "job received" message back from the print server. I was wortried that making these changes might end up in an increase of print jobs lost to the ether, but we haven't had any reports of this so far. Looks like we'll be okay until the next OSX update.