From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Subject: bug#30939: shepherd: detailed output should be placed into well-known location and not tty Date: Tue, 27 Mar 2018 20:59:46 +0200 Message-ID: <87370lcpjx.fsf@lassieur.org> References: <20180325183555.cilo6qyrj43jh6he@abyayala> <87a7uvdke0.fsf@gnu.org> <20180326150859.6yf244bgjxi4oawt@abyayala> <87o9jaynpn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0tpI-0003bh-Jw for bug-guix@gnu.org; Tue, 27 Mar 2018 15:00:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f0tpC-0001wH-SZ for bug-guix@gnu.org; Tue, 27 Mar 2018 15:00:08 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:48348) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f0tpC-0001w8-P7 for bug-guix@gnu.org; Tue, 27 Mar 2018 15:00:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f0tpC-0007oo-IS for bug-guix@gnu.org; Tue, 27 Mar 2018 15:00:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87o9jaynpn.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 30939@debbugs.gnu.org, ng0 Ludovic Courtès writes: > Hello, > > ng0 skribis: > >> Sometimes I succeed building a system generation with an OpenSMTPD config-file >> which has syntax error that aren't picked up at configure time. When I reboot, >> not being aware of this, I have to switch to tty to read the reasons why it >> crashed. >> Because this is a desktop system, I have to start the service again to see >> the error output directly from the daemon. > > I think shepherd could capture stdout/stderr of the processes it starts > and make it available, in a way similar in spirit to what ‘journalctl’ > does. That would allow you to see the output of the daemon that failed. That would be great! > That’s the only solution I can think of. Of course we don’t have to do > that if the daemon writes error messages to syslog, but not all of them do. > > Thanks, > Ludo’.