I was testing attachments and found out that if /tmp was filled up that
RT3 didn’t report that it had problems in the logs or user interface.
The ‘links’ for the attachments were there but not ‘clickable’ (ie only
the names really, not the links).
I had just upgraded to 3.0.9 so it took me a while to figure out it
wasn’t the upgrade but the lack of /tmp space. It would be good if it
told the user the attachment failed and logged something.
SteveN
I was testing attachments and found out that if /tmp was filled up
that RT3 didn’t report that it had problems in the logs or user
interface. The ‘links’ for the attachments were there but not
‘clickable’ (ie only the names really, not the links).I had just upgraded to 3.0.9 so it took me a while to figure out it
wasn’t the upgrade but the lack of /tmp space. It would be good if it
told the user the attachment failed and logged something.
Interesting. I’d love to see a bug report and (ideally) a patch to
rt-bugs@fsck.com.
Jesse Vincent wrote:
I was testing attachments and found out that if /tmp was filled up
that RT3 didn’t report that it had problems in the logs or user
interface. The ‘links’ for the attachments were there but not
‘clickable’ (ie only the names really, not the links).I had just upgraded to 3.0.9 so it took me a while to figure out it
wasn’t the upgrade but the lack of /tmp space. It would be good if
it told the user the attachment failed and logged something.Interesting. I’d love to see a bug report and (ideally) a patch to
rt-bugs@fsck.com.
This may be connected with (lack of) filesystem inodes.
Alex
Alex Soares de Moura wrote:
Jesse Vincent wrote:
I was testing attachments and found out that if /tmp was filled up
that RT3 didn’t report that it had problems in the logs or user
interface. The ‘links’ for the attachments were there but not
‘clickable’ (ie only the names really, not the links).I had just upgraded to 3.0.9 so it took me a while to figure out it
wasn’t the upgrade but the lack of /tmp space. It would be good if
it told the user the attachment failed and logged something.Interesting. I’d love to see a bug report and (ideally) a patch to
rt-bugs@fsck.com.This may be connected with (lack of) filesystem inodes.
I found i had to install tmpwatch to clean out files in /tmp older than
48 hours for things to work properly.
I was testing attachments and found out that if /tmp was filled up
that RT3 didn’t report that it had problems in the logs or user
interface. It would be good if it told the user the attachment
failed and logged something.Interesting. I’d love to see a bug report and (ideally) a patch to
rt-bugs@fsck.com.This may be connected with (lack of) filesystem inodes.
Sure. What should happen is that the MIME Parser should throw an
error which we should take up the chain and TMPFAIL on. Which I’m sort
of surprised isn’t happening.
Jesse
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jesse Vincent wrote:
On Mar 18, 2004, at 2:52 PM, neruda@lithik.com wrote:
I was testing attachments and found out that if /tmp was filled up
that RT3 didn’t report that it had problems in the logs or user
interface. The ‘links’ for the attachments were there but not
‘clickable’ (ie only the names really, not the links).I had just upgraded to 3.0.9 so it took me a while to figure out it
wasn’t the upgrade but the lack of /tmp space. It would be good if
it told the user the attachment failed and logged something.Interesting. I’d love to see a bug report and (ideally) a patch to
rt-bugs@fsck.com.Sorry about the procedure faupaux. I’m leaving town for the weekend
but will send a bug report to the correct address at the beginning of
next week.
No worries. You did nothing wrong at all. We’re always happy to hear
about issues in any form that people want to tell us about them (though
we have yet to get a bug report in crayon). Enjoy your weekend out of
town. I’m actually travelling next week, myself. (If any RT users in
Tokyo or Taipei want to say hello, send me mail personally)
Best,
Jesse
iD8DBQFAWgrNQaM/s3DrrJARAjhaAJ0R2LWqG9jq0OW6h2hd+tIbV/qLsACfes65
HraXgdhuuw/+nrblk8JBowY=
=Nd41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFAWgroQaM/s3DrrJARAl+fAKDVRgYAaBzgzUCUHB/1sOKiNWGkjgCdEKnu
AL6BCqDsobkbu7uK1v3TYUU=
=/D79
-----END PGP SIGNATURE-----