Description of problem: ABRT cannot report bugs to bugzilla or kerneloops from behind a proxy server. There exists no proxy configution for abrt. In fasc there exists no proxy configuration for system-wide services to use. Version-Release number of selected component (if applicable): abrt-0.0.11-1.fc12.x86_64 How reproducible: Always for me. I'm behind a university proxy for accessing the internet Steps to Reproduce: 1. Let something crash (kernel oops seems very common in my F12 :-) 2. Click on send in the abrt dialog that opens when clicking on the notification-icon Actual results: It keeps hanging for a while and then i've to kill Expected results: It should send the crash details Additional info:
Does it work for you when you're not behind a proxy? Can you try to restart abrtd daemon after you connect to the network and try to report again? Thanks, Jirka
I cannot test whether it works when not behind a proxy. I have to use the university proxy to access internet. After restarting the abrtd service, when i tried to report a crash (in blender) the doemon tried to do check for bug duplicates for some time and then i got the following message in a dialog box : "Unable to finish current task! org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." However the main window of abrt said about the blender crash "This crash has been reported. You can find the report at file:///var/log/abrt-logger". The file only contains the crash details (backtrace etc) and no info about any rhbz bug report. Abrt probably did not do anything. The only abrt reported bug for blender does not have me in cc (which i think abrt shud have done if it could connect to the internet) Another crash in abiword was also stopped at the same stage as the blender bug. But after the dbus error message, abrt said the abiword crash to be still unreported (and i checked there's no abrt reported bug for abiword). Abrt seems to mark the crash as reported if it is interrupted in between. So finally abrt did not work even after restarting the abrtd service behind proxy. Thanks, Pankaj
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 538168 has been marked as a duplicate of this bug. ***
Just to confirm that I too am getting a failure from ABRT which looks like it's because all of our network access has to go through a proxy. I have the http_proxy environment set and I have an auto-config file defined in my gnome settings under System > Preferences > Network Proxy. Unfortunately I too am unable to test whilst bypassing the proxy, but all other network activity on this machine is fine - it's only ABRT which seems to have a problem.
adding '. /etc/profile.d/proxy.sh' (or wherever your proxy is configured) to /etc/init.d/abrtd fixes the problem. There should be probably something added which reads such setup from /etc/sysconfig/abrtd.
Ok, i've simply added http_proxy=http://local.proxy.com:3128/ to /etc/init.d/abrtd Hope fully it will work for the next crash. By the way won't this file be replaced the next time abrtd is updated? There must be some better solution to it if that is so. And is there one way to set proxy for all things that require it, maybe setting it in inittab? I hate setting proxy in soo many places. Thanks
Seems like proxy is being set after abrtd is started and abrtd doesn't notice it. i;m going to push a new version to testing in a while, if someone care to test it. Thanks, Jirka
May be useful: how firefox was taught to use proxy settings: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/23369
comment #7: 'http_proxy' must be exported ('export http_proxy') and https_proxy should be set too.
Although my proxy settings are added to the startup of my system, Abrt didn't recognize it, Adding the proxy settings to /etc/init.d/abrtd did work for me after reloading abrtd daemon.
I added: # # Set these variables if you are behind proxy # #export http_proxy= #export https_proxy= to /etc/init.d/abrtd. Closing this bug.
*** Bug 557639 has been marked as a duplicate of this bug. ***
can you please add something like | ! test -e /etc/sysconfig/abrtd || . /etc/sysconfig/abrtd or mark the initscript as %config(noreplace)? Else, every update will override the settings.
Surely this should go into the existing config file at /etc/abrt/abrt.conf? Bonus points if it can pick it up directly from the environment where people have it set systemwide. Editing initscripts is not something a user should be encouraged to do. Since most people will only interact with the ABRT front end there should really be a way to set this from there, or have it pick up the gnome proxy configuration.
(In reply to comment #15) > Surely this should go into the existing config file at /etc/abrt/abrt.conf? And PATH, LANG, SHELL etc too? Why settle for one way to do something (e.g. setting environment variables for a process), lets have ten. Hint: if you want ALL your daemons have http_proxy set to the same value, _where_ should be set? "In each in every daemon" is a wrong answer... > Bonus points if it can pick it up directly from the environment where people > have it set systemwide. This is a good idea I want to implement. Where exactly people have http[s]_proxy set systemwide? > Editing initscripts is not something a user should be encouraged to do. > > Since most people will only interact with the ABRT front end there should > really be a way to set this from there, or have it pick up the gnome proxy > configuration. I agree. That's why I implemented _transparent_ proxy when I was working as admin. *No one* was needed to tweak anything on hundreds of their machines. But I digress...
*** Bug 559322 has been marked as a duplicate of this bug. ***
Surely adding proxy export to /etc/init.d/abrtd work, and i'm sure proxy handling is a pain for developers and users alike, and marking the initscript as %config(noreplace) is also probably not a good choice. Lately i've had to edit the initscript too often, as abrt is updated quite often. How about implementing a dbus service to get proxy details, since nowadays all things seem to go the dbus way :) >Hint: if you want ALL your daemons have http_proxy set to the same value, >_where_ should be set? "In each in every daemon" is a wrong answer... Yes this is surely not a good sign. I think you can take an initiative by sourcing the proxy vars from lets say some file /etc/sysconfig/system-proxy. Then any other system service which needs proxy to run should source it from that file (in fact any env var could be set in that file). In future a 'set system proxy' button could be added to the gnome-network-properties to set the system proxy in that file. NOTE: i'm not a developer so if any of this is crap please ignore it :)
(In reply to comment #18) > How about implementing a dbus service to get proxy details, since nowadays all > things seem to go the dbus way :) dbus service for env vars? It's kinda small. Let's use Oracle db ;) > >Hint: if you want ALL your daemons have http_proxy set to the same value, > >_where_ should be set? "In each in every daemon" is a wrong answer... > > Yes this is surely not a good sign. I think you can take an initiative by > sourcing the proxy vars from lets say some file /etc/sysconfig/system-proxy. > Then any other system service which needs proxy to run should source it from > that file no.. > (in fact any env var could be set in that file). YES! There is a place which starts all services at boot. That's the place where http_proxy can, and should, be set. After all, _something_ sets PATH env var for every started service. Why we are inventing yet another place and method to set other env vars? This problem isn't going to stop at http_proxy, some other services/programs may have other common variables.
abrt-1.0.7-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/abrt-1.0.7-1.fc12
abrt-1.0.7-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update abrt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1598
abrt-1.0.7-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
This has not been fixed, we need to find a way where to read the proxy setting, GNOME has it in gconf, KDE has it somewhere too, it can be set as a environment variable $http_proxy. Or should we do this per plugin? J.
Why does the abrtd daemon send the report and not the frontend? Configuring a system wide daemon with user specific settings (user 'foo' might use another proxy than user 'bar') does not sound like a good idea. When you want that the abrtd daemon sends reports unattendedly, then configure it like other daemons (manually edited /etc configuration files (inclusive /etc/sysconfig initscript configuration)).
(In reply to comment #24) > Why does the abrtd daemon send the report and not the frontend? It's planned to split the reporting part and the daemon, so the reporting part will then run under user who's trying to report and not under root. > Configuring a > system wide daemon with user specific settings (user 'foo' might use another > proxy than user 'bar') does not sound like a good idea. That's not what we want to do. The user settings are "forgotten" once used, but the problem is where to read the proxy setting? I don't like the idea to implementing this 10 times for 10 different desktops environments. To be clear I'm not against storing this setting per user (actually I like that idea) but just would like to have this at one place. Maybe networkmanager could know the proxy setting and then abrt fronted couls just ask networkmanager for the proxy setting. > > When you want that the abrtd daemon sends reports unattendedly, then configure > it like other daemons (manually edited /etc configuration files (inclusive > /etc/sysconfig initscript configuration)). Yes, this works for ABRT even in it's current version.
> I don't like the idea to implementing this 10 times for 10 different desktops environments 'libproxy' (http://code.google.com/p/libproxy/) should help here
Looks nice and easy, thanks for the info. J.
Using gnome proxy setting for setting proxy parameters, doesn't make abrt to pick them on Fedora 13
(In reply to comment #28) > Using gnome proxy setting for setting proxy parameters, doesn't make abrt to > pick them on Fedora 13 still not working in f14 alpha rc3.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
currently this is flagged 'NEEFINFO' for me, but i'm not sure what info is needed. The current workaround as per my knowledge is to edit the /etc/init.d/abrtd and put the proxy env vars after every update of abrt, which though works, is probably not documented anywhere else.
(In reply to comment #31) > currently this is flagged 'NEEFINFO' for me, but i'm not sure what info is > needed. > > The current workaround as per my knowledge is to edit the /etc/init.d/abrtd and > put the proxy env vars after every update of abrt, which though works, is > probably not documented anywhere else. How about putting the settings in /etc/sysconfig/abrtd and sourcing the file from the init script? That way we wouldn't have to edit the init script with every update.
(In reply to comment #31) > currently this is flagged 'NEEFINFO' for me, but i'm not sure what info is > needed. I think you should modify the bug in order to report it against FC14 rather than FC12 (or it will be closed by the bot) > The current workaround as per my knowledge is to edit the /etc/init.d/abrtd and > put the proxy env vars after every update of abrt, which though works, is > probably not documented anywhere else. I confirm that on FC14, kernel 2.6.35.6-48.fc14.x86_64, abrtd 1.1.13.2.fc14.x86_64 (last version)
I've tried on F15 and seems to be still there. I've edited startup script to export http/s proxy values and doesn't work. It *should* be configured on GUI in order to work for all users and 'honour' gnome proxy settings.
Editing the init file /etc/rc.d/init.d/abrtd to add proxy works but it breaks yum deltarpm updates and needs to be fixed: $ yum update [...] Setting up and reading Presto delta metadata Processing delta metadata /etc/rc.d/init.d/abrtd: contents have been changed delta does not match installed data This results in larger update download size
(In reply to comment #34) > I've tried on F15 and seems to be still there. > > I've edited startup script to export http/s proxy values and doesn't work. > > It *should* be configured on GUI in order to work for all users and 'honour' > gnome proxy settings. Fedora 15 no longer uses the init scripts (at least in the default configuration). The recommended way to fix this (acording to my reading of http://0pointer.de/blog/projects/on-etc-sysinit.html and some previous articles) is to: cp /lib/systemd/system/abrtd.service /etc/systemd/system/ and add an environment line: --------------- [Unit] Description=ABRT Automated Bug Reporting Tool After=syslog.target [Service] Type=dbus BusName=com.redhat.abrt ExecStart=/usr/sbin/abrtd -d -s Environment=http_proxy=http://proxy.example.com:80 https_proxy=http://proxy.example.com:80 [Install] WantedBy=multi-user.target ----------------- I haven't tested crash reporting yes, but the service did restart.
(In reply to comment #36) > Environment=http_proxy=http://proxy.example.com:80 > https_proxy=http://proxy.example.com:80 That should be a single line.
I could get the approach above #36/#37 working in Fedora 16, and so I can't make ABRT reports. (I can get the proxy to work for Firefox, so I know its not a networking/connectivity issue.) If you want bug reports when problems occur, then a better approach needs to be provided... its especially confusing when you can set proxy info in the Network settings and not have them apply to ABRT, Firefox, yum, etc...
I guess moving to systemd unit files breaks the old style proxy setting and it's time to actually implement it in abrt client.
if systemd breaks it, then it's a bug for systemd and should be fixed asap
The reporters now use libproxy to get the correct proxy setting. It should be able to take it from the Gnome, KDE or NetworkManager configuration. upstream commit 3bb284.
How do I find that upstream commit? What upcoming release will the commit be a part of?
@Sean git clone git://git.fedorahosted.org/git/libreport.git
abrt-2.0.7-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/abrt-2.0.7-2.fc16
Package abrt-2.0.7-2.fc16, libreport-2.0.8-3.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing abrt-2.0.7-2.fc16 libreport-2.0.8-3.fc16' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16990/libreport-2.0.8-3.fc16,abrt-2.0.7-2.fc16 then log in and leave karma (feedback).
abrt-2.0.7-2.fc16, libreport-2.0.8-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.