12:30 p.m.
This f20 server has been running just fine for months. Today it became
unresponsive. Couldn't ssh into it (ping ok). Not thrashing disk (disk light
not continuously on).
I hit the power button and rebooted. After reboot, checked /var/log/messages:
Feb 25 12:06:18 nbecker7 kernel: [ 49.667251] tun: Universal TUN/TAP device
driver, 1.6
Feb 25 12:06:18 nbecker7 kernel: [ 49.667254] tun: (C) 1999-2004 Max
Krasnyansky <maxk(a)qualcomm.com>
Feb 25 12:06:18 nbecker7 kernel: [ 59.015938] Ebtables v2.0 registered
Feb 25 12:06:18 nbecker7 kernel: [ 59.601221] ip6_tables: (C) 2000-2006
Netfilter Core Team
Feb 25 12:06:18 nbecker7 kernel: [ 65.646938] Bridge firewalling registered
Feb 25 12:06:18 nbecker7 kernel: [ 65.671316] device virbr0-nic entered
promiscuous mode
Feb 25 12:06:18 nbecker7 kernel: [ 66.410670] virbr0: port 1(virbr0-nic)
entered listening state
Feb 25 12:06:18 nbecker7 kernel: [ 66.410678] virbr0: port 1(virbr0-nic)
entered listening state
Feb 25 12:06:18 nbecker7 kernel: [ 66.410724] IPv6: ADDRCONF(NETDEV_UP):
virbr0: link is not ready
Feb 25 12:06:18 nbecker7 kernel: [ 66.668588] virbr0: port 1(virbr0-nic)
entered disabled state
Feb 25 12:06:54 nbecker7 kernel: [ 109.855407] fuse init (API version 7.22)
Jan 8 10:48:32 nbecker7 systemd: Stopped target Graphical Interface.
Jan 8 10:48:32 nbecker7 systemd: Stopping Multi-User System.
Jan 8 10:48:32 nbecker7 systemd: Stopped target Multi-User System.
Jan 8 10:48:32 nbecker7 systemd: Stopping ABRT kernel log watcher...
Jan 8 10:48:32 nbecker7 systemd: Stopping Command Scheduler...
Jan 8 10:48:32 nbecker7 systemd: Stopping Install ABRT coredump hook...
Jan 8 10:48:32 nbecker7 systemd: Stopping ABRT Xorg log watcher...
Jan 8 10:48:32 nbecker7 systemd: Stopping OpenSSH server daemon...
How did the date just become Jan 8??
5:58 a.m.
On Fri, Feb 28, 2014 at 8:54 AM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Feb 27, 2014, at 12:28 PM, Lars E. Pettersson <lars(a)homer.se> wrote:
> On 02/26/14 19:23, lee wrote:
>> What is the purpose of this log duplication? When systemd has its own
>> logs, it doesn´t seem necessary to duplicate them by sending their
>> contents to syslogd.
>
> One could also ask why systemd duplicates the logging formerly only done by syslogd.
This has been answered many times already, it's an old argument.
It's an old argument because someone who is scared of the argument is
trying to define it away.
[...]
It's fine to want plain logs but that is a subset of the amount of information the
journal can only
retain with binary including checksumming so the logs can be verified, and universal
time/date
stamping that causes journalctl to report the even in local time even if the server is
not local, the
list of things that can be done are unlimited. So the superset log is a necessity in any
case and
if the plain text rsyslog is meeting your needs then why would you bother with journalctl
at all?
Every time I see a defense of systemd and its spawn, I see this kind of bunk.
If information can be logged in binary form, it can be logged in human
readable form. It's just a matter of pushing the data through
appropriate filters, that's all.
The real problem with logs is what to retain and what to strip out.
And logs that can't be directly read by humans are not worth the
having. Nobody will read them until long after the bad things happened
and left the system corrupted.
Enforced universalism is the last thing we want computers for.
[...]
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
5:23 a.m.
On 02/28/2014 12:54 AM, Chris Murphy wrote:
On Feb 27, 2014, at 12:28 PM, Lars E. Pettersson <lars(a)homer.se> wrote:
> On 02/26/14 19:23, lee wrote:
>> What is the purpose of this log duplication? When systemd has its own
>> logs, it doesn´t seem necessary to duplicate them by sending their
>> contents to syslogd.
>
> One could also ask why systemd duplicates the logging formerly only done by syslogd.
This has been answered many times already, it's an old argument.
That was not my point of argument.
> For me looking through my ASCII-based text-logs created by
syslogd is far faster than using journalctl. Things that takes over 25 minutes with
journalctl, only takes 66 seconds grepping the syslogd logs. (see bug 1047719, that no-one
seems to care about)
Why are the logs so large? Each log file I have is either 8MB, 16MB, or maximum 24MB. So
somehow yours are getting very large before they are turned over. Also do you normally
search all logs for all time? Or are you searching in the most recent boot? You can use
journalctl -b -1 to search the last boot, -2 the one before that. It can be done using
--since with a date to encompass multiple boots yet not all boots. There is also -u to
filter by unit. If you have journalctl do some filtering in advance then not so much stuff
is dumped into grep to filter.
Why the journal is 4GB? Have no idea, perhaps you could enlighten me?
The syslogd created text files are only using about 700MB of space for
the same duration. The problem is not the size of the text files, the
problem is that systemd/journalctl is extremely sluggish when the
journal is big. If it takes 20-25 minutes to get the same information
from journalctl, when it takes about 1 minute going through all syslogd
created text-files for the same duration, then something is utterly
wrong with how the journal works, and if it (the journal) is supposed to
replace the syslogd generated text files, it has to be at least equally
fast to be usable.
Also note that this sluggishness creates problem for the 'systemctl
status' command, which is a really bad thing.
Using -b, --since, etc. is not the point, the point is the sluggishness
shown when the journal is big.
> ASCII-based logs can be read by anybody using any editor. To read
the journal you need journalctl, or similar program, as the journal is binary and not
readily readable.
It's fine to want plain logs but that is a subset of the amount of information the
journal can only retain with binary including checksumming so the logs can be verified,
and universal time/date stamping that causes journalctl to report the even in local time
even if the server is not local, the list of things that can be done are unlimited. So the
superset log is a necessity in any case and if the plain text rsyslog is meeting your
needs then why would you bother with journalctl at all?
That is all fine and dandy, but does not change the fact that a text
file can be read by anyone. The journal needs programs of some sort to
be read.
> Another reason is that there still exist programs/daemons/etc.
that rely on the logs in /var/log.
>
> If you do not like syslogd, well F20 does not ship it anymore…
I think the repo has both rsyslog and syslog-ng.
That does not change the fact that the F20 install has dameons etc. that
actually relies on a present MTA and/or the syslog daemon.
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
1:51 a.m.
On Fri, 28 Feb 2014 00:42:02 +0100
lee <lee(a)yun.yagibdah.de> wrote:
How do I disable these binary logs and have everything logged with
syslogd? Most of the logging goes there anyway.
systemctl mask systemd-journald.service
___
Regards
Frank
frankly3d.com
5:57 p.m.
On Feb 27, 2014, at 4:42 PM, lee <lee(a)yun.yagibdah.de> wrote:
"Lars E. Pettersson" <lars(a)homer.se> writes:
> On 02/26/14 19:23, lee wrote:
>> What is the purpose of this log duplication? When systemd has its own
>> logs, it doesn´t seem necessary to duplicate them by sending their
>> contents to syslogd.
>
> One could also ask why systemd duplicates the logging formerly only
> done by syslogd.
>
> For me looking through my ASCII-based text-logs created by syslogd is
> far faster than using journalctl. Things that takes over 25 minutes
> with journalctl, only takes 66 seconds grepping the syslogd logs. (see
> bug 1047719, that no-one seems to care about)
>
> ASCII-based logs can be read by anybody using any editor. To read the
> journal you need journalctl, or similar program, as the journal is
> binary and not readily readable.
>
> Another reason is that there still exist programs/daemons/etc. that
> rely on the logs in /var/log.
>
> If you do not like syslogd, well F20 does not ship it anymore...
What I don´t like is unnecessary double logging and hidden log files
that cannot be read without special software, like binary ones.
How do I disable these binary logs and have everything logged with
syslogd?
You can't turn off systemd-journald anymore than you can turn off systemd. It's an
integrated function. If you don't like the journal you can install syslog-nd or
rsyslog.
How do they think users will ever get a working system with no logging
and not even an mta installed?
It's an old argument, most users don't have a hard requirement on syslog or an
mta, therefore they aren't installed by default but they're still in the repo and
you can manually install them. Easy fix.
Chris Murphy
5:54 p.m.
On Feb 27, 2014, at 12:28 PM, Lars E. Pettersson <lars(a)homer.se> wrote:
On 02/26/14 19:23, lee wrote:
> What is the purpose of this log duplication? When systemd has its own
> logs, it doesn´t seem necessary to duplicate them by sending their
> contents to syslogd.
One could also ask why systemd duplicates the logging formerly only done by syslogd.
This has been answered many times already, it's an old argument.
For me looking through my ASCII-based text-logs created by syslogd is
far faster than using journalctl. Things that takes over 25 minutes with journalctl, only
takes 66 seconds grepping the syslogd logs. (see bug 1047719, that no-one seems to care
about)
Why are the logs so large? Each log file I have is either 8MB, 16MB, or maximum 24MB. So
somehow yours are getting very large before they are turned over. Also do you normally
search all logs for all time? Or are you searching in the most recent boot? You can use
journalctl -b -1 to search the last boot, -2 the one before that. It can be done using
--since with a date to encompass multiple boots yet not all boots. There is also -u to
filter by unit. If you have journalctl do some filtering in advance then not so much stuff
is dumped into grep to filter.
ASCII-based logs can be read by anybody using any editor. To read the
journal you need journalctl, or similar program, as the journal is binary and not readily
readable.
It's fine to want plain logs but that is a subset of the amount of information the
journal can only retain with binary including checksumming so the logs can be verified,
and universal time/date stamping that causes journalctl to report the even in local time
even if the server is not local, the list of things that can be done are unlimited. So the
superset log is a necessity in any case and if the plain text rsyslog is meeting your
needs then why would you bother with journalctl at all?
Another reason is that there still exist programs/daemons/etc. that rely on the logs in
/var/log.
If you do not like syslogd, well F20 does not ship it anymore…
I think the repo has both rsyslog and syslog-ng.
Chris Murphy
5:42 p.m.
"Lars E. Pettersson" <lars(a)homer.se> writes:
On 02/26/14 19:23, lee wrote:
> What is the purpose of this log duplication? When systemd has its own
> logs, it doesn´t seem necessary to duplicate them by sending their
> contents to syslogd.
One could also ask why systemd duplicates the logging formerly only
done by syslogd.
For me looking through my ASCII-based text-logs created by syslogd is
far faster than using journalctl. Things that takes over 25 minutes
with journalctl, only takes 66 seconds grepping the syslogd logs. (see
bug 1047719, that no-one seems to care about)
ASCII-based logs can be read by anybody using any editor. To read the
journal you need journalctl, or similar program, as the journal is
binary and not readily readable.
Another reason is that there still exist programs/daemons/etc. that
rely on the logs in /var/log.
If you do not like syslogd, well F20 does not ship it anymore...
What I don´t like is unnecessary double logging and hidden log files
that cannot be read without special software, like binary ones.
How do I disable these binary logs and have everything logged with
syslogd? Most of the logging goes there anyway.
How do they think users will ever get a working system with no logging
and not even an mta installed?
--
Fedora release 20 (Heisenbug)
1:28 p.m.
On 02/26/14 19:23, lee wrote:
What is the purpose of this log duplication? When systemd has its
own
logs, it doesn´t seem necessary to duplicate them by sending their
contents to syslogd.
One could also ask why systemd duplicates the logging formerly only done
by syslogd.
For me looking through my ASCII-based text-logs created by syslogd is
far faster than using journalctl. Things that takes over 25 minutes with
journalctl, only takes 66 seconds grepping the syslogd logs. (see bug
1047719, that no-one seems to care about)
ASCII-based logs can be read by anybody using any editor. To read the
journal you need journalctl, or similar program, as the journal is
binary and not readily readable.
Another reason is that there still exist programs/daemons/etc. that rely
on the logs in /var/log.
If you do not like syslogd, well F20 does not ship it anymore...
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
12:23 p.m.
"Lars E. Pettersson" <lars(a)homer.se> writes:
The syslog daemon writes whatever systemd sends to it. On one of my
systems systemd decided to send the whole systemd journal to the
syslog daemon, by doing so starting to write log lines from last year
in my /var/log/messages.
What is the purpose of this log duplication? When systemd has its own
logs, it doesn´t seem necessary to duplicate them by sending their
contents to syslogd.
--
Fedora release 20 (Heisenbug)
3:25 p.m.
On 02/25/2014 07:58 PM, Dale Dellutri wrote:
It didn't. Systemd is in control, and /var/log/messages is no
longer
necessarily
written in order. You need to use journalctl to read the log for F20.
The syslog daemon writes whatever systemd sends to it. On one of my
systems systemd decided to send the whole systemd journal to the syslog
daemon, by doing so starting to write log lines from last year in my
/var/log/messages. Quite annoying... It also hogged 100% of the CPU.
But, when systemd behaves, /var/log/messages should be in order. And you
do not need journalctl to read the log (as long as you have syslogd
installed).
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
1:22 p.m.
Ashley M. Kirchner wrote:
Besides the time changing, I'm also dying to know how (or WHY
rather) it
also decided to stop all those services.
I assume it's because I hit the power button. But it didn't actually shut down,
and after a while I held the power button to force it.
On Tue, Feb 25, 2014 at 11:30 AM, Neal Becker <ndbecker2(a)gmail.com> wrote:
> This f20 server has been running just fine for months. Today it became
> unresponsive. Couldn't ssh into it (ping ok). Not thrashing disk (disk
> light
> not continuously on).
>
> I hit the power button and rebooted. After reboot, checked
> /var/log/messages:
>
> Feb 25 12:06:18 nbecker7 kernel: [ 49.667251] tun: Universal TUN/TAP
> device
> driver, 1.6
> Feb 25 12:06:18 nbecker7 kernel: [ 49.667254] tun: (C) 1999-2004 Max
> Krasnyansky <maxk(a)qualcomm.com>
> Feb 25 12:06:18 nbecker7 kernel: [ 59.015938] Ebtables v2.0 registered
> Feb 25 12:06:18 nbecker7 kernel: [ 59.601221] ip6_tables: (C) 2000-2006
> Netfilter Core Team
> Feb 25 12:06:18 nbecker7 kernel: [ 65.646938] Bridge firewalling
> registered
> Feb 25 12:06:18 nbecker7 kernel: [ 65.671316] device virbr0-nic entered
> promiscuous mode
> Feb 25 12:06:18 nbecker7 kernel: [ 66.410670] virbr0: port 1(virbr0-nic)
> entered listening state
> Feb 25 12:06:18 nbecker7 kernel: [ 66.410678] virbr0: port 1(virbr0-nic)
> entered listening state
> Feb 25 12:06:18 nbecker7 kernel: [ 66.410724] IPv6: ADDRCONF(NETDEV_UP):
> virbr0: link is not ready
> Feb 25 12:06:18 nbecker7 kernel: [ 66.668588] virbr0: port 1(virbr0-nic)
> entered disabled state
> Feb 25 12:06:54 nbecker7 kernel: [ 109.855407] fuse init (API version
> 7.22)
> Jan 8 10:48:32 nbecker7 systemd: Stopped target Graphical Interface.
> Jan 8 10:48:32 nbecker7 systemd: Stopping Multi-User System.
> Jan 8 10:48:32 nbecker7 systemd: Stopped target Multi-User System.
> Jan 8 10:48:32 nbecker7 systemd: Stopping ABRT kernel log watcher...
> Jan 8 10:48:32 nbecker7 systemd: Stopping Command Scheduler...
> Jan 8 10:48:32 nbecker7 systemd: Stopping Install ABRT coredump hook...
> Jan 8 10:48:32 nbecker7 systemd: Stopping ABRT Xorg log watcher...
> Jan 8 10:48:32 nbecker7 systemd: Stopping OpenSSH server daemon...
>
> How did the date just become Jan 8??
>
> --
> users mailing list
> users(a)lists.fedoraproject.org
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org
>
>
1:03 p.m.
On Feb 25, 2014, at 11:58 AM, Dale Dellutri <daledellutri(a)gmail.com> wrote:
On Tue, Feb 25, 2014 at 12:30 PM, Neal Becker
<ndbecker2(a)gmail.com> wrote:
This f20 server has been running just fine for months. Today it became
unresponsive. Couldn't ssh into it (ping ok). Not thrashing disk (disk light
not continuously on).
I hit the power button and rebooted. After reboot, checked /var/log/messages:
Feb 25 12:06:18 nbecker7 kernel: [ 49.667251] tun: Universal TUN/TAP device
driver, 1.6
Feb 25 12:06:18 nbecker7 kernel: [ 49.667254] tun: (C) 1999-2004 Max
Krasnyansky <maxk(a)qualcomm.com>
Feb 25 12:06:18 nbecker7 kernel: [ 59.015938] Ebtables v2.0 registered
Feb 25 12:06:18 nbecker7 kernel: [ 59.601221] ip6_tables: (C) 2000-2006
Netfilter Core Team
Feb 25 12:06:18 nbecker7 kernel: [ 65.646938] Bridge firewalling registered
Feb 25 12:06:18 nbecker7 kernel: [ 65.671316] device virbr0-nic entered
promiscuous mode
Feb 25 12:06:18 nbecker7 kernel: [ 66.410670] virbr0: port 1(virbr0-nic)
entered listening state
Feb 25 12:06:18 nbecker7 kernel: [ 66.410678] virbr0: port 1(virbr0-nic)
entered listening state
Feb 25 12:06:18 nbecker7 kernel: [ 66.410724] IPv6: ADDRCONF(NETDEV_UP):
virbr0: link is not ready
Feb 25 12:06:18 nbecker7 kernel: [ 66.668588] virbr0: port 1(virbr0-nic)
entered disabled state
Feb 25 12:06:54 nbecker7 kernel: [ 109.855407] fuse init (API version 7.22)
Jan 8 10:48:32 nbecker7 systemd: Stopped target Graphical Interface.
Jan 8 10:48:32 nbecker7 systemd: Stopping Multi-User System.
Jan 8 10:48:32 nbecker7 systemd: Stopped target Multi-User System.
Jan 8 10:48:32 nbecker7 systemd: Stopping ABRT kernel log watcher...
Jan 8 10:48:32 nbecker7 systemd: Stopping Command Scheduler...
Jan 8 10:48:32 nbecker7 systemd: Stopping Install ABRT coredump hook...
Jan 8 10:48:32 nbecker7 systemd: Stopping ABRT Xorg log watcher...
Jan 8 10:48:32 nbecker7 systemd: Stopping OpenSSH server daemon...
How did the date just become Jan 8??
It didn't. Systemd is in control, and /var/log/messages is no longer necessarily
written in order. You need to use journalctl to read the log for F20.
Ahh I didn't pick up on these being from messages.
journalctl -b --no-pager # for the current boot
journalctl -b -1 --no-pager # for the boot before current, -2 for the one before that,
-3, -4, etc.
To get more information
journalctl -xb
It can also be piped
journalctl -b -1 | grep -i time
systemd itself doesn't manage or change time.
Chris Murphy
12:58 p.m.
On Tue, Feb 25, 2014 at 12:30 PM, Neal Becker <ndbecker2(a)gmail.com> wrote:
This f20 server has been running just fine for months. Today it
became
unresponsive. Couldn't ssh into it (ping ok). Not thrashing disk (disk
light
not continuously on).
I hit the power button and rebooted. After reboot, checked
/var/log/messages:
Feb 25 12:06:18 nbecker7 kernel: [ 49.667251] tun: Universal TUN/TAP
device
driver, 1.6
Feb 25 12:06:18 nbecker7 kernel: [ 49.667254] tun: (C) 1999-2004 Max
Krasnyansky <maxk(a)qualcomm.com>
Feb 25 12:06:18 nbecker7 kernel: [ 59.015938] Ebtables v2.0 registered
Feb 25 12:06:18 nbecker7 kernel: [ 59.601221] ip6_tables: (C) 2000-2006
Netfilter Core Team
Feb 25 12:06:18 nbecker7 kernel: [ 65.646938] Bridge firewalling
registered
Feb 25 12:06:18 nbecker7 kernel: [ 65.671316] device virbr0-nic entered
promiscuous mode
Feb 25 12:06:18 nbecker7 kernel: [ 66.410670] virbr0: port 1(virbr0-nic)
entered listening state
Feb 25 12:06:18 nbecker7 kernel: [ 66.410678] virbr0: port 1(virbr0-nic)
entered listening state
Feb 25 12:06:18 nbecker7 kernel: [ 66.410724] IPv6: ADDRCONF(NETDEV_UP):
virbr0: link is not ready
Feb 25 12:06:18 nbecker7 kernel: [ 66.668588] virbr0: port 1(virbr0-nic)
entered disabled state
Feb 25 12:06:54 nbecker7 kernel: [ 109.855407] fuse init (API version
7.22)
Jan 8 10:48:32 nbecker7 systemd: Stopped target Graphical Interface.
Jan 8 10:48:32 nbecker7 systemd: Stopping Multi-User System.
Jan 8 10:48:32 nbecker7 systemd: Stopped target Multi-User System.
Jan 8 10:48:32 nbecker7 systemd: Stopping ABRT kernel log watcher...
Jan 8 10:48:32 nbecker7 systemd: Stopping Command Scheduler...
Jan 8 10:48:32 nbecker7 systemd: Stopping Install ABRT coredump hook...
Jan 8 10:48:32 nbecker7 systemd: Stopping ABRT Xorg log watcher...
Jan 8 10:48:32 nbecker7 systemd: Stopping OpenSSH server daemon...
How did the date just become Jan 8??
It didn't. Systemd is in control, and /var/log/messages is no longer
necessarily
written in order. You need to use journalctl to read the log for F20.
--
Dale Dellutri
12:43 p.m.
Besides the time changing, I'm also dying to know how (or WHY rather) it
also decided to stop all those services.
On Tue, Feb 25, 2014 at 11:30 AM, Neal Becker <ndbecker2(a)gmail.com> wrote:
This f20 server has been running just fine for months. Today it
became
unresponsive. Couldn't ssh into it (ping ok). Not thrashing disk (disk
light
not continuously on).
I hit the power button and rebooted. After reboot, checked
/var/log/messages:
Feb 25 12:06:18 nbecker7 kernel: [ 49.667251] tun: Universal TUN/TAP
device
driver, 1.6
Feb 25 12:06:18 nbecker7 kernel: [ 49.667254] tun: (C) 1999-2004 Max
Krasnyansky <maxk(a)qualcomm.com>
Feb 25 12:06:18 nbecker7 kernel: [ 59.015938] Ebtables v2.0 registered
Feb 25 12:06:18 nbecker7 kernel: [ 59.601221] ip6_tables: (C) 2000-2006
Netfilter Core Team
Feb 25 12:06:18 nbecker7 kernel: [ 65.646938] Bridge firewalling
registered
Feb 25 12:06:18 nbecker7 kernel: [ 65.671316] device virbr0-nic entered
promiscuous mode
Feb 25 12:06:18 nbecker7 kernel: [ 66.410670] virbr0: port 1(virbr0-nic)
entered listening state
Feb 25 12:06:18 nbecker7 kernel: [ 66.410678] virbr0: port 1(virbr0-nic)
entered listening state
Feb 25 12:06:18 nbecker7 kernel: [ 66.410724] IPv6: ADDRCONF(NETDEV_UP):
virbr0: link is not ready
Feb 25 12:06:18 nbecker7 kernel: [ 66.668588] virbr0: port 1(virbr0-nic)
entered disabled state
Feb 25 12:06:54 nbecker7 kernel: [ 109.855407] fuse init (API version
7.22)
Jan 8 10:48:32 nbecker7 systemd: Stopped target Graphical Interface.
Jan 8 10:48:32 nbecker7 systemd: Stopping Multi-User System.
Jan 8 10:48:32 nbecker7 systemd: Stopped target Multi-User System.
Jan 8 10:48:32 nbecker7 systemd: Stopping ABRT kernel log watcher...
Jan 8 10:48:32 nbecker7 systemd: Stopping Command Scheduler...
Jan 8 10:48:32 nbecker7 systemd: Stopping Install ABRT coredump hook...
Jan 8 10:48:32 nbecker7 systemd: Stopping ABRT Xorg log watcher...
Jan 8 10:48:32 nbecker7 systemd: Stopping OpenSSH server daemon...
How did the date just become Jan 8??
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
3716
days inactive
3719
days old
13 comments
8 participants
participants (8)
-
Ashley M. Kirchner -
Chris Murphy -
Dale Dellutri -
Frank Murphy -
Joel Rees -
Lars E. Pettersson -
lee -
Neal Becker