[rt-users] Apache FastCGI and # of db connections
Hi, Thanks very much for Request Tracker! I have a question regarding behaviour of FastCGI processes and database connections. While preparing upgrade of RT 3.8.16 to RT 4.2.1 I noticed a change of FastCGI usage in the RT. I am using Debian Wheezy (with some packages from Jessie/Sid to satisfy dependencies) and PostgreSQL as database backend on it. I have a four instances of RT connecting to one PostgreSQL server. FastCGI processes of my old instances (3.8.16) was configured in the Apache: FastCgiServer /opt/eu/bin/mason_handler.fcgi -idle-timeout 400 -processes 9 -init-start-delay 1 FastCgiServer /opt/interni/bin/mason_handler.fcgi -idle-timeout 400 -processes 2 -init-start-delay 2 FastCgiServer /opt/nis/bin/mason_handler.fcgi -idle-timeout 400 -processes 9 -init-start-delay 2 FastCgiServer /opt/RT/bin/mason_handler.fcgi -idle-timeout 400 -processes 9 -init-start-delay 1 So I have a total number of 3 * 9 + 2 = 29 FastCGI processes and the same number of database connections: rt=# select count(*) from pg_stat_activity where usename like 'rt_%'; count --- 29 (1 row) Note: all RT DB accounts starts with `rt_'. I have limited number of database connection on the server: rt:~# grep ^max_connections /etc/postgresql/9.1/main/postgresql.conf max_connections = 48# (change requires restart) And this number (48) is sufficient so. During testing of RT 4.2.1 instances on the testing box with modified configuration according to web_deployment.pod I got after a while exhausted database connections. I noticed every FastCGI process forks one child (Placks default?), that delays database connection to HTTP request time, so I ended up with two times number of DB connections than before. I tried to configure one fresh instance: Directory /opt/rt4-preview Options FollowSymLinks ExecCGI AllowOverride None /Directory FastCgiServer /opt/rt4-preview/sbin/rt-server.fcgi -processes 5 -idle-timeout 300 ScriptAlias /rt4 /opt/rt4-preview/sbin/rt-server.fcgi this is according to docs/web_deployment.pod I hope. During Apache startup, it is possible for a moment to see processes: \_ /usr/bin/perl -w /opt/rt4-preview/sbin/rt-server.fcgi which quickly transforms into daemonized couple: \_ perl-fcgi-pm | \_ perl-fcgi After a while the situation is (pstree): ├─apache2─┬─apache2─┬─5*[perl-fcgi-pm───perl-fcgi] │ │ └─3*[rt-index.fcgi] │ └─5*[apache2] Till no request is handled the connections are: zito=# select count(*) from pg_stat_activity where usename like 'rt_%'; count --- 5 (1 row) The number of connections grows during requests on web interface and ends with: zito=# select count(*) from pg_stat_activity where usename like 'rt_%'; count --- 10 (1 row) All children processes are connected to database... Is this setup really ok? I did not study Plack too much - only look at http://search.cpan.org/~miyagawa/Plack-1.0030/lib/Plack/Handler/FCGI.pm and there is approach a bit different. One daemon is started standalone (forking to a number of processes) and Apache is configured to connect to this daemon FastCgiExternalServer /tmp/myapp.fcgi -socket /tmp/fcgi.sock But I don't know technology. Should I really increase PostgreSQL max_connections to 100 and don't bother with it? Best Regards -- Zito
[rt-users] Autoreply to new requestors
I have a scrip that, when a ticket is created by email by under certain conditions, will delete the email sender as the requestor and replace it with a different requestor (in order to permit creating tickets on behalf of others). I have confirmed this scrip works properly, and that this scrip executes prior to the default scrip which autoreplies to ticket creators. Yet, the autoreply is being sent to the email sender and not to the new requestor. Does anyone have a suggestion to ensure the autoreply is sent to the newly-set requestor and not the email sender? -Abe -- View this message in context: http://requesttracker.8502.n7.nabble.com/Autoreply-to-new-requestors-tp56239.html Sent from the Request Tracker - User mailing list archive at Nabble.com.
Re: [rt-users] Autoreply to new requestors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/10/14, 12:17 PM, Abraham Liebsch wrote: I have a scrip that, when a ticket is created by email by under certain conditions, will delete the email sender as the requestor and replace it with a different requestor (in order to permit creating tickets on behalf of others). I have confirmed this scrip works properly, and that this scrip executes prior to the default scrip which autoreplies to ticket creators. Yet, the autoreply is being sent to the email sender and not to the new requestor. Does anyone have a suggestion to ensure the autoreply is sent to the newly-set requestor and not the email sender? Is the Autoreply scrip before or after the replace-the-requestor scrip? Best, - --Glenn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLQMNkACgkQf5MxTDXTimFVegCfUqnGPBGfytg9wTziYNGZft4o 6pYAmgKS82cMFgwjFnn46iDubwRZ7fIw =76uH -END PGP SIGNATURE-
[rt-users] Resolve without Stealing
I am trying to find a way to allow my Tier 1 team to resolve tickets without stealing tickets. At this point if someone works on a ticket for two days, or 1 hour, and completes the ticket, the client usually replies back with a thank you or Yup, everything is good to go. I do not want another Tier 1 person to have to Steal the ticket to resolve it. One caveat about this request is that I know there is a permission out there, Edit Ticket, but that gives them a lot more features which I do not want them to have. Specifically, being able to reply to any ticket even if they are not the owner. Kind of long winded but hopefully someone can help.
Re: [rt-users] Autoreply to new requestors
It appears to be running afterwards. I've renamed the scripts, prepending 100 to the reassignment scrip and 110 to the autoreply scrip, so that they are listed in the proper order, and confirmed in the apache log that the requestors are changed before the autoreply scrip is run. Unless there is an order-of-execution nuance that escapes me, it appears that the requestor is replaced first. I could be missing something, though, as there is another scrip that, according to the log, is executing between those two, despite not being listed between them. -Original Message- From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Glenn Sieb Sent: Friday, January 10, 2014 11:42 AM To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Autoreply to new requestors -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/10/14, 12:17 PM, Abraham Liebsch wrote: I have a scrip that, when a ticket is created by email by under certain conditions, will delete the email sender as the requestor and replace it with a different requestor (in order to permit creating tickets on behalf of others). I have confirmed this scrip works properly, and that this scrip executes prior to the default scrip which autoreplies to ticket creators. Yet, the autoreply is being sent to the email sender and not to the new requestor. Does anyone have a suggestion to ensure the autoreply is sent to the newly-set requestor and not the email sender? Is the Autoreply scrip before or after the replace-the-requestor scrip? Best, - --Glenn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLQMNkACgkQf5MxTDXTimFVegCfUqnGPBGfytg9wTziYNGZft4o 6pYAmgKS82cMFgwjFnn46iDubwRZ7fIw =76uH -END PGP SIGNATURE- smime.p7s Description: S/MIME cryptographic signature
[rt-users] RT4.2.1 + Fetchmail + Office365 - MDA returned nonzero status 75
Hi, I recently changed of company and was asked to set a request system. Off course I'm setting up RT4. Problem is that in this new job they use Office365 as the Mail Server. So I tryied something new to me that is the use of the Fetchmail to retrieve from the server and then deliver to RT using the mail Gateway. The problem is the MDA is returning code 75. I was looking in the history of the mailing list and other doccuments and this code is refered for several problems. None of them seems to relate with my config. May you please give a look at mail fetchmail config and LOG to tell me any ideia of what could be wrong? Thank you in advance! Request Tracker 4.2.1 over Ubuntu 13.10. root@SRV-RT:/opt/rt4/var# cat /etc/fetchmailrc set daemon 300 set no bouncemail defaults: antispam -1 batchlimit 100 nofetchall nokeep poll pod51028.outlook.com with proto IMAP port 993 username r...@stitelecom.com.brmailto:r...@stitelecom.com.br password xx mda /opt/rt4/bin/rt-mailgate --url https://rt.stitelecom.local --queue General --action correspond ssl username rt-comm...@stitelecom.com.brmailto:rt-comm...@stitelecom.com.br password xxx mda /opt/rt4/bin/rt-mailgate --url https://rt.stitelecom.local --queue General --action comment ssl root@SRV-RT:/home/sti# cat /var/log/syslog Jan 10 17:11:27 SRV-RT fetchmail[29468]: Old UID list from pod51028.outlook.com: empty Jan 10 17:11:27 SRV-RT fetchmail[29468]: Old UID list from pod51028.outlook.com: empty Jan 10 17:11:27 SRV-RT fetchmail[29468]: Scratch list of UIDs: empty Jan 10 17:11:27 SRV-RT fetchmail[29469]: starting fetchmail 6.3.26 daemon Jan 10 17:11:27 SRV-RT fetchmail[29469]: 6.3.26 querying pod51028.outlook.com (protocol IMAP) at Fri 10 Jan 2014 05:11:27 PM BRST: poll started Jan 10 17:11:28 SRV-RT fetchmail[29469]: Trying to connect to 132.245.156.22/993...connected. Jan 10 17:11:28 SRV-RT fetchmail[29469]: Certificate chain, from root to peer, starting at depth 3: Jan 10 17:11:28 SRV-RT fetchmail[29469]: Issuer Organization: Baltimore Jan 10 17:11:28 SRV-RT fetchmail[29469]: Issuer CommonName: Baltimore CyberTrust Root Jan 10 17:11:28 SRV-RT fetchmail[29469]: Subject CommonName: Baltimore CyberTrust Root Jan 10 17:11:28 SRV-RT fetchmail[29469]: Certificate at depth 2: Jan 10 17:11:28 SRV-RT fetchmail[29469]: Issuer Organization: Baltimore Jan 10 17:11:28 SRV-RT fetchmail[29469]: Issuer CommonName: Baltimore CyberTrust Root Jan 10 17:11:28 SRV-RT fetchmail[29469]: Subject CommonName: Microsoft Internet Authority Jan 10 17:11:28 SRV-RT fetchmail[29469]: Certificate at depth 1: Jan 10 17:11:28 SRV-RT fetchmail[29469]: Unknown Organization Jan 10 17:11:28 SRV-RT fetchmail[29469]: Issuer CommonName: Microsoft Internet Authority Jan 10 17:11:28 SRV-RT fetchmail[29469]: Subject CommonName: MSIT Machine Auth CA 2 Jan 10 17:11:28 SRV-RT fetchmail[29469]: Server certificate: Jan 10 17:11:28 SRV-RT fetchmail[29469]: Unknown Organization Jan 10 17:11:28 SRV-RT fetchmail[29469]: Issuer CommonName: MSIT Machine Auth CA 2 Jan 10 17:11:28 SRV-RT fetchmail[29469]: Subject CommonName: outlook.com Jan 10 17:11:28 SRV-RT fetchmail[29469]: Subject Alternative Name: outlook.com Jan 10 17:11:28 SRV-RT fetchmail[29469]: Subject Alternative Name: *.outlook.com Jan 10 17:11:28 SRV-RT fetchmail[29469]: Subject Alternative Name: *.exchangelabs.com Jan 10 17:11:28 SRV-RT fetchmail[29469]: Subject Alternative Name: m.outlook.com Jan 10 17:11:28 SRV-RT fetchmail[29469]: Subject Alternative Name: m.exchangelabs.com Jan 10 17:11:28 SRV-RT fetchmail[29469]: pod51028.outlook.com key fingerprint: E7:48:66:D7:91:A5:5F:CA:5E:CE:27:5D:0B:10:4C:5E Jan 10 17:11:29 SRV-RT fetchmail[29469]: IMAP * OK The Microsoft Exchange IMAP4 service is ready. [RwBSAFUAUABSAEQAOAAwADEAMQBDAEEAMAAwADMALgBsAGEAbQBwAHIAZAA4ADAALgBwAHIAbwBkAC4AbwB1AHQAbABvAG8AawAuAGMAbwBtAA==] Jan 10 17:11:29 SRV-RT fetchmail[29469]: IMAP A0001 CAPABILITY Jan 10 17:11:29 SRV-RT fetchmail[29469]: IMAP * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+ Jan 10 17:11:29 SRV-RT fetchmail[29469]: IMAP A0001 OK CAPABILITY completed. Jan 10 17:11:29 SRV-RT fetchmail[29469]: Protocol identified as IMAP4 rev 1 Jan 10 17:11:29 SRV-RT fetchmail[29469]: GSSAPI error gss_inquire_cred: Unspecified GSS failure. Minor code may provide more information Jan 10 17:11:29 SRV-RT fetchmail[29469]: GSSAPI error gss_inquire_cred: Success Jan 10 17:11:29 SRV-RT fetchmail[29469]: No suitable GSSAPI credentials found. Skipping GSSAPI authentication. Jan 10 17:11:29 SRV-RT fetchmail[29469]: If you want to use GSSAPI, you need credentials first, possibly from kinit. Jan 10 17:11:29 SRV-RT fetchmail[29469]: IMAP A0002 LOGIN r...@stitelecom.com.brmailto:r...@stitelecom.com.br * Jan 10 17:11:36 SRV-RT fetchmail[29469]: IMAP A0002 OK LOGIN completed. Jan 10 17:11:36 SRV-RT fetchmail[29469]: selecting or re-polling default folder Jan 10 17:11:36 SRV-RT
Re: [rt-users] Resolve without Stealing
Tom, We got rid of the On Correspond Open Tickets Scrip to avoid tickets being reopened because of those type of responses. Is that an option for you, or would you like your tickets to re-open? -Nate On Fri, Jan 10, 2014 at 1:33 PM, Tom Leslein tlesl...@arsalon.net wrote: I am trying to find a way to allow my Tier 1 team to resolve tickets without stealing tickets. At this point if someone works on a ticket for two days, or 1 hour, and completes the ticket, the client usually replies back with a thank you or “Yup, everything is good to go.” I do not want another Tier 1 person to have to Steal the ticket to resolve it. One caveat about this request is that I know there is a permission out there, “Edit Ticket”, but that gives them a lot more features which I do not want them to have. Specifically, being able to reply to any ticket even if they are not the owner. Kind of long winded but hopefully someone can help.
Re: [rt-users] Resolve without Stealing
Thank you, but no. Regretfully I still need to allow our clients to re-open tickets. I just need to allow my team to resolve tickets of anyone's without Stealing the ticket. From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Nathan Baker Sent: Friday, January 10, 2014 4:01 PM Cc: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Resolve without Stealing Tom, We got rid of the On Correspond Open Tickets Scrip to avoid tickets being reopened because of those type of responses. Is that an option for you, or would you like your tickets to re-open? -Nate On Fri, Jan 10, 2014 at 1:33 PM, Tom Leslein tlesl...@arsalon.netmailto:tlesl...@arsalon.net wrote: I am trying to find a way to allow my Tier 1 team to resolve tickets without stealing tickets. At this point if someone works on a ticket for two days, or 1 hour, and completes the ticket, the client usually replies back with a thank you or Yup, everything is good to go. I do not want another Tier 1 person to have to Steal the ticket to resolve it. One caveat about this request is that I know there is a permission out there, Edit Ticket, but that gives them a lot more features which I do not want them to have. Specifically, being able to reply to any ticket even if they are not the owner. Kind of long winded but hopefully someone can help.
Re: [rt-users] Apache FastCGI and # of db connections
On Fri, 2014-01-10 at 11:45 +0100, Václav Ovsík wrote: I have a question regarding behaviour of FastCGI processes and database connections. While preparing upgrade of RT 3.8.16 to RT 4.2.1 I noticed a change of FastCGI usage in the RT. Thanks for bringing this to our attention. This is a bug which affects RT 4.0 and 4.2; the 4.0/fewer-active-handles branch resolves the issue. I did not study Plack too much - only look at http://search.cpan.org/~miyagawa/Plack-1.0030/lib/Plack/Handler/FCGI.pm and there is approach a bit different. One daemon is started standalone (forking to a number of processes) and Apache is configured to connect to this daemon FastCgiExternalServer /tmp/myapp.fcgi -socket /tmp/fcgi.sock This is a valid alternate deployment strategy, which comes with the benefit that one can restart one RT server without affecting others, by restarting its fastcgi process. However, it requires additional system configuration to ensure that these processes are started at server startup time, and so forth, which is why this is not the deployment suggested in RT's documentation, which we aim to keep as simple as possible. Should I really increase PostgreSQL max_connections to 100 and don't bother with it? Until a version of RT is released with the above branch, increasing the max_connections is likely your best bet. The additional connections will consume some small amount of memory each, but this is likely negligible, and will have no performance impact. - Alex
