Bug 1261212 - puppet agent terminates with SIGTERM
puppet agent terminates with SIGTERM
Status: NEW
Product: Fedora EPEL
Classification: Fedora
Component: puppet (Show other bugs)
epel7
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeroen van Meeuwen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-08 19:11 EDT by Randy Zagar
Modified: 2018-02-07 14:36 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Randy Zagar 2015-09-08 19:11:15 EDT
Description of problem:
puppet seems to crash regularly and generate a crash report (from abrt)

Version-Release number of selected component (if applicable):
RHEL-7.1, puppet-3.6.2, 

How reproducible:


Steps to Reproduce:
1. install puppet via EPEL
2. let puppet run
3. look for crash reports from abrt

Actual results:
time:           Thu 03 Sep 2015 07:34:02 AM CDT
cmdline:        /usr/bin/ruby /usr/bin/puppet agent --no-daemonize
uid:            0 (root)
abrt_version:   2.1.11
event_log:      
executable:     /usr/bin/puppet
hostname:       fakename
kernel:         3.10.0-229.11.1.el7.x86_64
last_occurrence: 1441752591
pid:            14216
pkg_arch:       noarch
pkg_epoch:      0
pkg_name:       puppet
pkg_release:    3.el7
pkg_version:    3.6.2
runlevel:       N 5
username:       root

sosreport.tar.xz: Binary file, 10978496 bytes

backtrace:
:/usr/share/ruby/optparse.rb:213:in `<top (required)>': SIGTERM (SignalException)
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/ruby/vendor_ruby/puppet/application.rb:1:in `<top (required)>'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/ruby/vendor_ruby/puppet/transaction.rb:3:in `<top (required)>'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/ruby/vendor_ruby/puppet/resource/catalog.rb:3:in `<top (required)>'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/ruby/vendor_ruby/puppet/parser/compiler.rb:4:in `<top (required)>'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/ruby/vendor_ruby/puppet/parser.rb:5:in `<top (required)>'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/ruby/vendor_ruby/puppet.rb:260:in `<top (required)>'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/ruby/vendor_ruby/puppet/util/command_line.rb:12:in `<top (required)>'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
:	from /usr/bin/puppet:7:in `<main>'


Expected results:
no report from abrt

Additional info:
This is a standard RHEL7 install with no packages installed other than what's provided via RHEL or EPEL.
Comment 1 lars.solberg 2015-11-13 04:16:41 EST
This is happening to me as well, but in my case it caused a little cascading effect  that I will look at some more before reporting them as separate bugzilla's.

Basically;
 * Puppet crashed (as in this bugzilla, it does that a lot, see below!)
 * abrt starts it's reporting, one of them being generating sosreport.
 * sosreport tries to run 'lsusb -t', which gets a hanging segfault.
 * the segfault hangs (http://stackoverflow.com/questions/33673592/segmentation-fault-itself-is-hanging), and a restart of abrtd is needed to "unhang" the segfaults on the system. This makes abrt-status hangs waiting for the lock of the abrt reporting the initial puppet crash. Basically causing the login (to root), (the act of loading bash profiles), to hang.


Some of the abrt reports that I have on one of my servers (so you can see how often this is happening);
2015-09-28-12:44:54-1169
2015-09-28-13:40:40-1072
2015-09-28-14:09:56-14117
2015-09-29-08:32:47-6034
2015-09-29-08:34:02-10123
2015-09-29-08:37:19-18028
2015-09-29-08:41:35-26645
2015-09-29-08:46:04-5029
2015-09-29-08:47:43-9266
2015-09-29-08:52:30-20664
2015-09-29-08:53:48-23668
2015-09-29-08:57:20-30389
2015-09-29-09:22:40-27493
2015-09-29-09:32:15-14669
2015-09-29-09:56:12-6562
2015-09-29-09:57:00-8015
2015-09-29-09:59:27-12439
2015-09-29-10:36:50-14058
2015-09-29-10:49:01-17968
2015-09-29-11:23:18-28189
2015-09-29-11:24:59-31388
2015-09-29-12:29:26-10304
2015-09-29-12:32:13-15898
2015-10-02-13:38:11-1786
2015-11-12-10:07:50-19083
2015-10-02-13:42:41-2038
2015-10-02-13:36:41-1645
2015-10-02-13:41:11-1955
2015-10-01-13:34:39-15231
2015-10-01-13:46:11-29721
2015-10-01-13:50:04-2894
2015-10-01-14:12:02-21134
2015-10-02-13:39:41-1869
2015-10-02-13:44:12-2120
2015-10-02-10:57:55-32358
2015-10-02-13:45:42-2208
2015-11-12-10:01:49-11825
2015-11-12-10:03:19-17738
2015-11-12-10:04:50-18834
2015-11-12-10:06:20-18968
Comment 2 Dominic Cleal 2017-05-23 07:38:33 EDT
Randy, are your crashes with the same stack trace and exception (SIGTERM received)? It indicates that the service is being stopped perhaps, as it's an external signal rather than a crash.

Can you provide journalctl output of the affected time period to show if a service stop was requested?


Lars, I'm not sure the ABRT issues are due to Puppet, but if you have the same SIGTERM error as above, perhaps you can provide additional information.

I've been unable to find similar reports on ABRT's retrace server.

Note You need to log in before you can comment on or make changes to this bug.