It's funny, for me it's the opposite - logging with systemd is sooo much better
than with Upstart. (IIRC, the logging of stderr of Upstart jobs was a
NixOS-specific hack, and other than that there was no logging support.)
Somehow, it work reliably…
However, there is a long-standing issue with
Hi,
On 02/09/14 11:50, Michael Raskin wrote:
It's funny, for me it's the opposite - logging with systemd is sooo much
better
than with Upstart. (IIRC, the logging of stderr of Upstart jobs was a
NixOS-specific hack, and other than that there was no logging support.)
Somehow, it work
On Tue, Sep 2, 2014 at 12:51 PM, Eelco Dolstra
eelco.dols...@logicblox.com wrote:
Hi,
On 02/09/14 11:50, Michael Raskin wrote:
It's funny, for me it's the opposite - logging with systemd is sooo much
better
than with Upstart. (IIRC, the logging of stderr of Upstart jobs was a
It's funny, for me it's the opposite - logging with systemd is sooo much
better
than with Upstart. (IIRC, the logging of stderr of Upstart jobs was a
NixOS-specific hack, and other than that there was no logging support.)
Somehow, it work reliably…
It did not. There was no way with
On 09/02/2014 07:30 AM, Michael Raskin wrote:
So all in all: it writes to a file in a way that ensures fragmentation,
then reads it randomly in small chunks, reads most of it, and ends up
way slower than just reading the entire file…
Could it be a bad interaction with COW of btrfs? I've also
On Tue, Sep 02, 2014 at 12:22:33PM +0200, Vladimír Čunát wrote:
On 09/02/2014 07:30 AM, Michael Raskin wrote:
So all in all: it writes to a file in a way that ensures fragmentation,
then reads it randomly in small chunks, reads most of it, and ends up
way slower than just reading the entire
However, there is a long-standing issue with stdout/stderr logging: if the
process dies before systemd has had a change to process its log message, then
systemd may not be able to figure out the unit corresponding to the message,
so
it may be lost (or not attributed to the unit). See
Hi,
On 02/09/14 11:58, Paul Colomiets wrote:
On 02/09/14 11:50, Michael Raskin wrote:
It's funny, for me it's the opposite - logging with systemd is sooo much
better
than with Upstart. (IIRC, the logging of stderr of Upstart jobs was a
NixOS-specific hack, and other than that there was no
On 02/09/14 12:06, Michael Raskin wrote:
It did not. There was no way with Upstart to get the log output of a service.
In NixOS the problem wasn't noticeable…
Again, the logging situation with systemd is vastly superior than it was with
Upstart. With Upstart you simply couldn't do something
It did not. There was no way with Upstart to get the log output of a
service.
In NixOS the problem wasn't noticeable…
Again, the logging situation with systemd is vastly superior than it was with
Upstart. With Upstart you simply couldn't do something like systemctl status
foo.service and
I also don't see these issues with journald (on non-SSD systems).
I would like to add I absolutely love systemd, as it provides proper
dependency management, helping immensely for more dynamic setups where
hardware changes should trigger services reconfiguration, or for
changing
I would like to add I absolutely love systemd, as it provides proper
dependency management, helping immensely for more dynamic setups where
hardware changes should trigger services reconfiguration, or for
changing services/vpn/routing based on wifi access point and more.
It's really nice that -
FWIW, yesterday I've also experienced loss of stderr messages in a service
I was trying to debug. In this case, it might have been either because the
process exited immediately afterwards or because of rate limiting, I don't
know which.
I've also always experienced HDD thrashing issues on
Shea Michael: By default systemd sends stdout stderr to the journal,
this is controlled by DefaultStandardOutput DefaultStandardError in
systemd-system.conf. So yes, if these are set to `journal` (or stdout is
set to `journal` and stderr to `inherit`) and you had stdout/stderr
messages which
14 matches
Mail list logo
