[SERVER-1635] Stray output from "puppetserver start" command Created: 2016/11/07  Updated: 2018/02/16  Resolved: 2018/02/16

Status: Closed
Project: Puppet Server
Component/s: Puppet Server
Affects Version/s: SERVER 2.7.0
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: Kurt Wall Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: maintenance
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to SERVER-1634 "puppetserver stop" command leaves su... Closed
Template:
Acceptance Criteria:
  • Warning output from puppetserver start goes into /var/log/mumble

 Description   

The puppetserver start command allows a warning message through to the CLI that should be sent to a log file somewhere. On a CentOS 6.5 system running Puppet Server (FOSS) 2.6.1.master.SNAPSHOT.2016.11.04T2126 and Puppet 4.8.1:

# puppetserver --version
puppetserver version: 2.6.1.master.SNAPSHOT.2016.11.04T2126
# puppetserver start
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
service puppetserver status
# service puppetserver status
puppetserver (pid  16743) is running...

Seems like that OpenJDK warning should go to /var/log/mumble.



 Comments   
Comment by Jeremy Barlow [ 2016/11/08 ]

This one probably relates somewhat to the conversation we're having in SERVER-1634 about whether we should document the "start" and "stop" subcommands as being for troubleshooting / development purposes only and encourage users to only use the service framework start/stop commands instead.

That said, I think this is one that we "could" do by adding something like the following to the Java command line in the start subcommand:

2>>/var/log/puppetlabs/${realname}/${realname}-daemon.log >>/var/log/puppetlabs/${realname}/${realname}-daemon.log

I'm inclined, though, to think that we shouldn't do this. One issue is that we only use the "daemon" log on pre-systemd systems. For systemd, stderr / stdout from the Java process today is redirected to the journal. If we were to put work into the start script to pipe the output to a log file, we might end up with three different locations that users would have to monitor for their log output on systemd systems - journal, daemon log, and service log. This would seem like a regression to me.

Rob Braden, Melissa Stone, Chris Price - would be interested in your thoughts on this one.

Generated at Wed Nov 13 16:51:32 PST 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.