Hey all;
Here's my situation with CUPS.
# rpm -qa | grep -i cups
cups-libs-1.3.11-1
hal-cups-utils-0.5.2-8.2
cups-lpd-1.3.11-1
libgnomecups-0.1.12-6
cups-1.3.11-1
# cat redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 8)
I know RH4 is upgradeable, and I don't know if cups the most recent version, but either way, I'm not permitted to change anything software wise, so I have to deal with what I've got as-is. This is a customers machine that the company I work for runs and operates. The customer has zero access to the CLI.
So here's my problem.
Every few months, the customer calls in reporting stair-casing on their text-only documents. The "Fix" is to restart cups, and then magically it starts working as expected. Its a disruption to their normal work flow, and is rather annoying to deal with. Last night I received a support request about the stair case issue on a very specific printer. So I logged in, changed the print driver to the PPD we tweaked to get to work with the printer and eliminate the stair casing. Didn't work. So then I changed to the "Default" printer (Excluding the -m parameter on the lpadmin command) and all of a sudden it work. A few minutes later, I received a phone call about it asking me what I did. I explained in less-than-technical details that I just changed the printer driver. Turns out that the printer they were testing on WASN'T even the printer I was working on. The printer I was working on was on the other side of the airport. The printer that they were testing on was actually the printer that was being miserable.
Let me explain in a different way.
- Printer next to them is borked.
- Printer across the airport is technically in an unknown state pre-and-post reconfiguration.
- Changes made to distant printer twice
- Printer next to them starts working
- At no time was any configuration change made to the printer next to them.
- The printer worked as expected the day before, today, it doesn't.
I checked the error logs to verify what driver the printer was actually using. Since Jan 24, there were 130 jobs sent to the printer near by. The printers in the crew room looks to have sent around 1,100 jobs, but the number of emails sent out via cups is much, much higher. These numbers come up based on the command:
# grep {printerrootname} * | grep -i ppd | wc
Why would "all of a sudden" CUPS decide that it needs to print in stair case mode? Since I can go back to the 24th with the current set of logs, can anyone advise what I can look at to try and determine what is happening?
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
Here's my situation with CUPS.
# rpm -qa | grep -i cups
cups-libs-1.3.11-1
hal-cups-utils-0.5.2-8.2
cups-lpd-1.3.11-1
libgnomecups-0.1.12-6
cups-1.3.11-1
# cat redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 8)
I know RH4 is upgradeable, and I don't know if cups the most recent version, but either way, I'm not permitted to change anything software wise, so I have to deal with what I've got as-is. This is a customers machine that the company I work for runs and operates. The customer has zero access to the CLI.
So here's my problem.
Every few months, the customer calls in reporting stair-casing on their text-only documents. The "Fix" is to restart cups, and then magically it starts working as expected. Its a disruption to their normal work flow, and is rather annoying to deal with. Last night I received a support request about the stair case issue on a very specific printer. So I logged in, changed the print driver to the PPD we tweaked to get to work with the printer and eliminate the stair casing. Didn't work. So then I changed to the "Default" printer (Excluding the -m parameter on the lpadmin command) and all of a sudden it work. A few minutes later, I received a phone call about it asking me what I did. I explained in less-than-technical details that I just changed the printer driver. Turns out that the printer they were testing on WASN'T even the printer I was working on. The printer I was working on was on the other side of the airport. The printer that they were testing on was actually the printer that was being miserable.
Let me explain in a different way.
- Printer next to them is borked.
- Printer across the airport is technically in an unknown state pre-and-post reconfiguration.
- Changes made to distant printer twice
- Printer next to them starts working
- At no time was any configuration change made to the printer next to them.
- The printer worked as expected the day before, today, it doesn't.
I checked the error logs to verify what driver the printer was actually using. Since Jan 24, there were 130 jobs sent to the printer near by. The printers in the crew room looks to have sent around 1,100 jobs, but the number of emails sent out via cups is much, much higher. These numbers come up based on the command:
# grep {printerrootname} * | grep -i ppd | wc
Why would "all of a sudden" CUPS decide that it needs to print in stair case mode? Since I can go back to the 24th with the current set of logs, can anyone advise what I can look at to try and determine what is happening?
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
