Opensuse Boot Time

Using the echo > /var/log/journal/MACHINEID/system.journal and echo > /var/log/journal/MACHINEID/user-1000.journal said by Malcolm, i got this systemd-analyze critical chain:


graphical.target @19.375s
└─multi-user.target @19.375s
  └─cron.service @19.375s
    └─postfix.service @17.051s +2.321s
      └─network.target @17.050s
        └─NetworkManager.service @15.842s +1.206s
          └─SuSEfirewall2_init.service @14.087s +1.753s
            └─basic.target @12.039s
              └─timers.target @12.038s
                └─systemd-tmpfiles-clean.timer @12.038s
                  └─sysinit.target @12.038s
                    └─apparmor.service @11.328s +710ms
                      └─systemd-tmpfiles-setup.service @10.973s +353ms
                        └─local-fs.target @10.959s

A better time boot for sure rotfl! . Thanks conram, Carlos, gogalthorp and Malcolm for all the help, help me understand better how my machine works too. I only question me now if i need to do this periodically to clean my journal or exist a easy method to do in YaST?

(Oh, and i almost forgot, Malcolm asked about the plymouth and my plymouth it seems that works when want)

On Thu 11 Dec 2014 10:06:01 PM CST, marcusvcl wrote:

Using the echo > /var/log/journal/MACHINEID/system.journal and echo >
/var/log/journal/MACHINEID/user-1000.journal said by Malcolm, i got this
systemd-analyze critical chain:

graphical.target @19.375s

A better time boot for sure rotfl! . Thanks conram, Carlos, gogalthorp
and Malcolm for all the help, help me understand better how my machine
works too. I only question me now if i need to do this periodically to
clean my journal or exist a easy method to do in YaST?

Hi
Indeed a better time :wink:

Ok, so what setting is in /etc/systemd/journal.conf ‘Storage’ which
should be ‘auto’?


Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.28-4-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

Hi Malcolm, my journal.conf have this:


[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=login
#SyncIntervalSec=5m
#RateLimitInterval=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#TTYPath=/dev/tty10
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info

Hi
Hmmm, so does it still show up as permanent if you run;


journalctl -a|grep journal

Yes, i ran the journalctl -a|grep journal and i saw the permanent use.


Dez 11 19:10:06 Marcus systemd-journal[401]: Journal started
Dez 11 19:10:19 Marcus systemd-journal[401]: Permanent journal is using 32.0M (max allowed 4.0G, trying to leave 4.0G free of 26.6G available → curren

Hi
Not really sure, maybe your disk type and size of / mine is 40GB on a 320GB HDD.

I guess just keep an eye on it.

On 2014-12-11 23:06, marcusvcl wrote:
>
> Using the echo > /var/log/journal/MACHINEID/system.journal and echo >
> /var/log/journal/MACHINEID/user-1000.journal said by Malcolm, i got this
> systemd-analyze critical chain:

>
> --------------------

Well, I’m flabbergasted. Flushing the journal was not in the critical
path, yet it was holding it up…


>      30.170159] Marcus systemd-journal[408]: Permanent journal is using 88.0M (max allowed 4.0G, trying to leave 4.0G free of 26.7G available → current
>      95.315146] Marcus systemd-journal[408]: Time spent on flushing to /var is 1min 5.144624s for 915 entries.

Almost 65 seconds flushing the cache and doing nothing else! This, to
me, looks like a bug in systemd. A large one.

That the journal on disk is terribly slow, because its designers all use
fast flash media instead of rotating disks, I knew. But that flushing
the journal is a blocking op, I did not.

IMO, the permanent solution is to install syslog, which automatically
should disable permanent systemd journal.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Hi
I don’t think it is a bug. I have five systems with 8GB RAM, four SLE and one openSUSE, 3 have rotating rust, two have ssd/rotating rust/bcache, all show;


systemd-journal[108]: Runtime journal is using 8.0M (max allowed 394.0M, trying to leave 591.0M free of 3.8G available → current limit 394.0M).

How/why is the OP’s system ‘Permanent’?

Hi Carlos, i made a search in openSUSE software and i found rsyslog, syslog-ng and syslogd. Can i install any of these?

rsyslog is fine.

As root; zypper in -y rsyslog && systemctl enable rsyslog && systemctl start rsyslog

Hi
And doing that will potentially destroy any chance of figuring out the issue…

You know, I’ve noticed that after years of doing this - I no longer read things, I just reply when people ask for something like “How do I…”

I think I should read more and answer less rotfl!

On 2014-12-12 04:46, malcolmlewis wrote:

> Hi
> I don’t think it is a bug. I have five systems with 8GB RAM, four SLE
> and one openSUSE, 3 have rotating rust, two have ssd/rotating
> rust/bcache, all show;

No, the bug is that boot processing stops while the log flush proceeds.
A whole minute.

> How/why is the OP’s system ‘Permanent’?

Because /var/log/journal/ directory exists? When that directory exists
(If I got the name right, I going from memory) then the journal is made
permanent on disk. There is an rpm package that creates it. I believe it
is the default on 13.2


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On 2014-12-12 13:26, Miuku wrote:
>
> rsyslog is fine.

That’s what I use.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Hi
Hmmm, both systemd-logger and /var/log/journal/machineid exist for me, still only a runtime journal…

To be honest I’ve never looked at the journal state until this thread as never had boot issues like this.

On Fri 12 Dec 2014 12:46:01 PM CST, Miuku wrote:

malcolmlewis;2682365 Wrote:
> And doing that will potentially destroy any chance of figuring out the
> issue…
You know, I’ve noticed that after years of doing this - I no longer read
things, I just reply when people ask for something like “How do I…”

I think I should read more and answer less rotfl!

LOL, I’m guilty of the same…


Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.28-4-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

Hi Miuku,
i haven’t installed rsyslog yet. But i don’t know if i need to install the syslog or we try to figure what is the issue. I notice that my journal is getting bloated again. Took 3sec to flush one time, 5 sec, 11 sec now. Maybe these 11sec was a isolated problem and don’t happen again. I need to do more test to determine if is the case.
In addition, thanks for all the reply, guys.

On Fri 12 Dec 2014 12:06:01 PM CST, marcusvcl wrote:

robin_listas;2682288 Wrote:
>
> IMO, the permanent solution is to install syslog, which automatically
> should disable permanent systemd journal.
>
Hi Carlos, i made a search in openSUSE software and i found rsyslog,
syslog-ng and syslogd. Can i install any of these?

Hi
Perhaps setting the logging storage option in the file I indicated
earlier from auto to none and then reboot and see if it changes to
‘Runtime’ zero out the logging files and see how it goes.

What I envisage is happening is since the files contain data, the auto
option is setting it to permanent.

Other options from man journald.conf are “volatile”, “persistent”,
“auto” and “none”. I’m assuming volatile is Runtime.


Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.28-4-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

Hi Malcolm,
I’ll set the storage option to none and volatile to see what happen with each one. I’ll use my machine normally, made some reboots and watch the logs. :slight_smile:

Hi
Then you probably need to look at the journals to see which one is growing and why… obviously something is generating traffic to fill them… :wink:

I think the fact that they are filling is potentially the symptom, we need to confirm and see what the potential problem is…