Re: [rt-users] apache 100% cpu usage

2011-03-21 Thread Payam Poursaied
I tried to examine your idea about big search. I did some of them (i.e. 128000 
results) but httpd process only peaked (still not 100%) and in a few seconds 
get back to the normal state.

It seems search with large result could not be the exact source if this problem

 

Best Regards

 

From: rt-users-boun...@lists.bestpractical.com 
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Payam Poursaied
Sent: Sunday, March 20, 2011 8:55 PM
To: 'Ruslan Zakirov'
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] apache 100% cpu usage

 

Hi Ruslan

Thank you for your response.

There isn’t any end! Even after a week!

All modules are updated to the latest available port in FreeBSD

 

You gave me a good point to check, but still I am curious to know how such 
problems could be debugged. Do you have any idea on this issue ?

 

Best Regards

 

 

From: Ruslan Zakirov [mailto:ruslan.zaki...@gmail.com] 
Sent: Sunday, March 20, 2011 7:39 PM
To: Payam Poursaied
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] apache 100% cpu usage

 

I see storable perl module there, so it's sessions handling. Look at updates 
for the module. Try to wait to see if it ends. If it ends then may be It's 
result of a big search that stored in the session. Newer versions of RT don't 
store big search results in sessions, only limited amount of records. Check 
sessions table for big records.

Regards, Ruslan. From phone.

20.03.2011 11:19 пользователь Payam Poursaied m...@payam124.com написал:
 
 Hi all
 We are using rt3.8.8 and we faced with a problem using apache 1.3.42 on 
 FreeBSD 8.0-RELEASE.
 The problem is that httpd processes frequently reach 100% CPU usage and stay
 at this level of CPU usage. 
 This is a sample of top output. 
 
 PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
 77051 www 1 118 0 208M 86080K CPU4 4 87.6H 100.00% httpd
 9403 www 1 118 0 215M 93340K CPU2 2 65.0H 100.00% httpd
 78430 www 1 118 0 226M 100M CPU0 0 58:57 100.00% httpd
 95332 www 1 50 0 205M 83624K sbwait 12 0:02 4.49% httpd
 89664 www 1 46 0 210M 88144K sbwait 11 0:05 2.59% httpd
 95331 www 1 46 0 205M 83464K sbwait 12 0:01 1.66% httpd

 
 I think there might be a bug that caused something like endless loop but I
 am newbie to gdb and debugging and I could not find any relevant point to
 get into it.
 I tried to compile apache in debug mode and then wait to see a suspicious
 process and then attached GDB66 to that cpu intensive httpd process to find
 out what is going on. 
 But I could not go further more.
 
 I have also consulted with apache-freebsd mailing list but there wasn't any 
 success.
 
 Could anyone help me to drill down this problem?
 
 Best Regards
 Payam Poursaied
 
 Using next says:
 (gdb) next
 Cannot find bounds of current function
 And here below is output of where command in gdb66.
 (gdb) where
 #0 0x00080093a73b in ?? () from /lib/libc.so.7
 #1 0x00080093d505 in ?? () from /lib/libc.so.7
 #2 0x0008009401bc in ?? () from /lib/libc.so.7
 #3 0x000800942ec4 in malloc () from /lib/libc.so.7
 #4 0x000803079946 in Perl_safesysmalloc () from 
 /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so
 #5 0x00080308cee0 in Perl_av_extend () from 
 /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so
 #6 0x00080308dabe in Perl_av_store () from 
 /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so
 #7 0x00080750de53 in retrieve_byte () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #8 0x00080750c66b in retrieve () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #9 0x0008075113b8 in retrieve_hash () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #10 0x00080750c66b in retrieve () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #11 0x00080750ce29 in retrieve_ref () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #12 0x00080750c66b in retrieve () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #13 0x0008075113b8 in retrieve_hash () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #14 0x00080750c66b in retrieve () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #15 0x00080751298c in retrieve_blessed () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #16 0x00080750c66b in retrieve () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #17 0x00080750ce29 in retrieve_ref () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #18 0x00080750c66b in retrieve () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #19 0x0008075113b8 in retrieve_hash () from 
 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Storable/Storable.so
 #20 0x00080750c66b in retrieve () from 
 

Re: [rt-users] Some advice on initial config

2011-03-21 Thread Nick Porter


Okay, that makes sense. So I thought a different approach might be in order.

Instead of having ExtertnalAuth create the privileged RT support users I'd have 
it create and authenticate all users as none unprivileged and manually set the 
support users to the correct group.

The first problem I've encountered is that ExternalAuth doesn't seem to 
recognise the 'Domain Users' group in AD. It works fine if I explicitly add the 
user to the 'RT User' users group I set up from the wiki howto doc but not if I 
either set the 'Domain Users' group in the ExternalAuth RT_SiteConfig.pm or if 
I add it as a member of the 'RT Users' group. Anybody know why that might be as 
adding them individually to 'RT User' will be a pain.

Thx for any feedback.

-np



--
Tradar Limited  is a limited company registered in England and Wales. 
Registered number: 3431380.
Registered office: 11 Conway Street, London. W1T 6BL

-Original Message-
From: rt-users-boun...@lists.bestpractical.com 
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Thomas Sibley
Sent: 18 March 2011 16:48
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Some advice on initial config

On 18 Mar 2011 12:31, Nick Porter wrote:


 Hello. I've been Googling and wiki reading and following the sterling advice 
 of others but I have to admit I'm stuck and could do with some help.

 I'm on Debain Squeeze, Apache2 and RT3.8 with MySQL

 I've got it the web interface up and even managed to get emails to flow from 
 our exchange server into the general queue so I have the basics.

 My problem is with the users. I've managed to get the ExternalAuth plugin to 
 talk to AD/ldap and create privileged user but I'm having problem setting RT 
 up so that the folks submitting emails/tickets to it can log in and see the 
 queue and theirs/others tickets.

 An email will arrive and create a ticket and create a user with *NOPASSWORD* 
 but for the life of me I can't seem to be able to login with that user. Even 
 is if users has the 'Let this user acess RT' check set.

These are internal unprivileged users that aren't authenticating through 
ExternalAuth and you've configured external auth to fall through to internal 
users?  If so, they need a password to login.

Thomas

 Any pointers as to what I should be looking for or what common pitfall I'm 
 encountering?

 Thx.
 --
 np




 --
 Tradar Limited  is a limited company registered in England and Wales. 
 Registered number: 3431380.
 Registered office: 11 Conway Street, London. W1T 6BL






Re: [rt-users] CF appears after update even without SeeCustomField rights

2011-03-21 Thread David Good
On 2/9/2011 2:46 PM, David Good wrote:
 On 2/9/2011 8:29 AM, Kevin Falcone wrote:
 On Tue, Feb 08, 2011 at 10:31:25AM -0800, David Good wrote:
 I've found an issue in two separate 3.8.8 installations.  Both have one
 or more CustomFields that are not supposed to be visible to most users. 
 The CF is managed entirely by Scrips to contain extra information not
 needed by users.  In one installation, it contains the Cost Center of
 the Requestor. In the other, there's a flag used to enable suppression
 of notifications when a ticket is resolved and another flag used to mark
 a ticket as 'urgent'.

 When using the web interface (i.e. via the 'Basics' or 'Jumbo' tab), the
 CF doesn't appear intially but after an update is made to any item and
 saved, the CustomField appear.
 David

 I'd be interested to know if you can reproduce this on a test box
 running the 3.8.9 release candidate

 -kevin
 I don't have a test box handy, but I'll see if I can get one setup.


I finally was able to upgrade one of the affected instances to 3.8.9 and
can confirm that my problem has been fixed.



[rt-users] RT Content-Type default to text/html

2011-03-21 Thread Narayanaswamy, Nagaraj
Hello,

Based on setting the content-type to text/html, looks like RT would send it as 
multi-part message with both text and HTML as attachments.

https://github.com/bestpractical/rt/blob/rt-3.8.7/docs/templates.pod#Special_Headers

I was wondering if there is a way to always have the default email  as HTML, 
and does not go out as multi-part email. Basically the email can be viewed 
directly in Outlook and other email clients supporting HTML rather than asking 
users to open attachments explicitly.

Thanks,


Re: [rt-users] RT Content-Type default to text/html

2011-03-21 Thread Kevin Falcone
On Mon, Mar 21, 2011 at 12:29:11PM -0400, Narayanaswamy, Nagaraj wrote:
Based on setting the content-type to text/html, looks like RT would send 
 it as multi-part
message with both text and HTML as attachments.

It sends as multipart/alternative so your MUA chooses which one to
display.  RT doesn't support sending HTML only email.

You should provide more specifics about what your templates look like,
sample RT email, your RT version, more information about how Outlook
mishandles it, etc etc.

-kevin

 

 [1]https://github.com/bestpractical/rt/blob/rt-3.8.7/docs/templates.pod#Special_Headers
 
 
 
I was wondering if there is a way to always have the default email  as 
 HTML, and does not go
out as multi-part email. Basically the email can be viewed directly in 
 Outlook and other email
clients supporting HTML rather than asking users to open attachments 
 explicitly.


pgpdhNPNwUUSG.pgp
Description: PGP signature