Custom Query (1145 matches)

Reported by geofft, 15 years ago.

I logged in to a cluster machine today. /proc/mounts had 65571 entries in it, including 63356 instances of what appear to be bind-mounts of /media. My xterm that I launch from .startup.X started after about two minutes at a black screen. GNOME took a while longer, and I noticed this issue because stracing gnome-terminal indicated it was trying to read /proc/mounts and that was taking a long time. I think this is what people are reporting when they say some cluster machines take them several minutes to log in...

See  /mit/geofft/Public/proc-mounts-uniq-c for the output of cat /proc/mounts | uniq -c and  /mit/geofft/Public/debathena-over-65000 for the relevant kernel logs wherein I pressed alt-sysrq-T and -W a bunch.

Reported by kchen, 16 years ago.

On my feisty machine, printing from acroread is broken:

Traceback (most recent call last):

File "/usr/bin/lpr", line 131, in <module>

fn(*fn_args)

File "/usr/bin/lpr", line 63, in useCups

if queue == None or cupsQueueExists(queue) or not lprngQueueExists(queue):

File "/usr/bin/lpr", line 45, in cupsQueueExists

return returnCode('/usr/bin/lpq.debathena-orig', '-P%s' % queue) == 0

File "/usr/bin/lpr", line 40, in returnCode

return call(command, stdout=PIPE, stderr=PIPE)

File "/usr/lib/python2.5/subprocess.py", line 443, in call

return Popen(*popenargs, kwargs).wait()

File "/usr/lib/python2.5/subprocess.py", line 1166, in wait

pid, sts = self._waitpid_no_intr(self.pid, 0)

File "/usr/lib/python2.5/subprocess.py", line 1007, in _waitpid_no_intr

return os.waitpid(pid, options)

OSError: [Errno 10] No child processes

Printing from other programs works fine.

Reported by broder, 15 years ago.

I'm reopening this bug, since geofft commandeered it from me originally.

Regardless of what our long-term plan for printing-config is or isn't, it is really unacceptable that, not only is there no way to set user-global print settings, but the documented way to do so only sometimes works, and the reasons for it sometimes working are completely opaque.

If the arguments passed to lpr can be interpreted purely as CUPS arguments (such as if you just do lpr -Pfoo), then the arguments in LPROPT aren't inserted into the processed command-line arguments. LPROPT arguments should always be added to the command-line, regardless of what printing technology the request ultimately gets back-ended to.

See also  RT:1098339,  RT:1141197, and undoubtedly others.