case study - journalctl - where is logger output

Tom H tomh0665 at gmail.com
Tue Sep 16 13:52:16 UTC 2014


On Sat, Sep 13, 2014 at 11:47 AM, Balint Szigeti <balint.szgt at gmail.com> wrote:
> On Thu, 2014-09-11 at 16:16 -0400, Tom H wrote:
>
> On Thu, Sep 11, 2014 at 2:04 PM, Balint Szigeti <balint.szgt at gmail.com>
> wrote:
>
>
>> today I installed the rsyslog and enable it then disabled (then masked)
>> systemd-journal-flush, systemd-journald services. Plus I disabled
>> systemd-journald.socket as well.
>> It broke my system. After I closed the sudo session I could gain root
>> access
>> plus I couldn't start any program only forks for the existed ones (like
>> gnome terminal).
>> The reboot didn't work. The box just didn't start up. :( (just remark -
>> systemd is not depends on itself........)
>
> I disabled all of the journal service and socket units and rebooted
> without a hitch. It was in an X-less VM though so perhaps things go
> awry when booting a DE (I don't see why it whould).
>
>
>> I booted into runlevel 1 (yeeeah - runlevel doesn't exist on systemd - I
>> wanted to say rescue.target) and redo the mask and enable everything.
>
> I boot into runlevel 1 when I use "1" on the kernel cmdline.
>
>
>> I've noticed the rsyslog doesn't listen to the system logging.
>>
>> I've run logger command but I don't find it in the log. I've checked the
>> journalctl and /var/log/messages file as well.
>>
>> # logger -t AAAA hello
>> # journalctl |grep hello
>> # grep hello /var/log/messages
>> #
>
> Same here.
>
> Is journald supposed to be turned off when using systemd? Why do you
> want it off? You can set "Storage=volatile" in
> "/etc/systemd/journald.conf" and 1) you'll only have rsyslog logs
> across reboots and 2) the journald logs will be written to the
> "/run/log/journal/" tmpfs so journald will simply collect logs for
> rsyslog.
>
> I've just tried to set the Storage entry in /etc/systemd/journald.conf  to
> "none" according to manual page and off course no effect.
> Also tried to set LogTarget to "syslog" in /etc/systemd/system.conf and
> reboot (funny, hurray we become Windows......)but no effect.
>
> Needless to say, the logs are being found in journalctl and messages file of
> course. I don't think to raise bug because any time when they hear someone
> doesn't want to use their 'solutions' they refuse/ignore or set the ticket
> to WONTFIX.
> Personally that is my bigger problem.
>
> I finished testing the syslog. I think the only thing that we can do to
> accept and shut our mouth :(

It's working here. systemd must sense that you don't like it and it's
messin' wit' u!

# grep Storage /etc/systemd/journald.conf
Storage=none

# ll /var/log/journal/
total 0

# ll /run/systemd/journal/
total 4
srw-rw-rw-. 1 root root 0 Sep 16 09:45 dev-log
-rw-r--r--. 1 root root 0 Sep 16 09:45 flushed
-rw-r--r--. 1 root root 8 Sep 16 09:45 kernel-seqnum
srw-rw-rw-. 1 root root 0 Sep 16 09:45 socket
srw-rw-rw-. 1 root root 0 Sep 16 09:45 stdout

# jc --list-boots
 0 db26ae69f1714eafb3058bcbc8d257c6 Tue 2014-09-16 09:45:09 EDT—Tue
2014-09-16 09:45:11 EDT

# jc
-- Logs begin at Tue 2014-09-16 09:45:09 EDT, end at Tue 2014-09-16
09:45:11 EDT. --
Sep 16 09:45:09 localhost systemd-journal[86]: Runtime journal is
using 6.0M (max allowed 48.6M, trying to leave 73.0M free of 480.7M
available → current limit 48.6M).
Sep 16 09:45:09 localhost systemd-journal[86]: Runtime journal is
using 6.0M (max allowed 48.6M, trying to leave 73.0M free of 480.7M
available → current limit 48.6M).
Sep 16 09:45:09 localhost kernel: Initializing cgroup subsys cpuset
Sep 16 09:45:09 localhost kernel: Initializing cgroup subsys cpu
Sep 16 09:45:09 localhost kernel: Initializing cgroup subsys cpuacct
Sep 16 09:45:09 localhost kernel: Linux version
3.17.0-0.rc4.git4.1.fc22.x86_64
(mockbuild at bkernel01.phx2.fedoraproject.org) (gcc version 4.9.1
20140813 (Red Hat 4.9.1-7) (GCC) ) #1 SMP Fri Sep 12 17:34:49 UTC 2014
Sep 16 09:45:09 localhost kernel: Command line:
BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc4.git4.1.fc22.x86_64
root=UUID=5bac0a63-0755-4127-9521-ae59faee6327 ro
...


More information about the users mailing list