Re: [systemd-devel] Newer videos

[guenther kuenzel]

if this is true, then the distribution is actually forced to move it to be 
compliant with FHS3. which is also a good thing, because /usr might not be 
available during boot time.

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

/lib Libraries essential for the binaries in /bin and /sbin.

/usr/lib Libraries for the binaries in /usr/bin and /usr/sbin.

which systemd
/bin/systemd

greetings




Am 22.01.18 um 08:19 schrieb Mantas Mikulėnas:
> On Sun, Jan 21, 2018 at 4:21 PM, Cecil Westerhof  > wrote:
> > I wanted to dive deeper into systemd. So I sought videos on YouTube. The 
> > most current I found was:
> >     https://www.youtube.com/watch?v=S9YmaNuvw5U
> >
> > But that one is 2½ years old. Is there something more recent? It was 
> > certainly interesting, but it is not completely up-to-date. For example
> >     /usr/lib/systemd/system
> > is now:
> >     /lib/systemd/system
>
> It is not. That's something your distro has changed.
>
> -- 
> Mantas Mikulėnas
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-journald missing crash logs

[guenther kuenzel]

the kernel itself has a remote dump functionality. this might be your only 
option when your system is not even able to write logs anymore.

https://help.ubuntu.com/lts/serverguide/kernel-crash-dump.html

greetings


Am 22.01.18 um 04:53 schrieb Farzad Panahi:
> Hi Lennart - Thanks for your comments.
>  
> On Mon, Jan 15, 2018 at 4:11 AM, Lennart Poettering  > wrote:
>
> On Fr, 12.01.18 16:13, Farzad Panahi (farzad.pan...@gmail.com 
> ) wrote:
>
> > I am running Arch-ARM on RPi3. I have noticed when system crashes I 
> cannot
> > find any related crash log in journal logs.
>
> What specifically is a "crash" supposed to mean?
>
>
> Crash in my case means that the box becomes unresponsive. Meaning that I 
> cannot ssh to it anymore until it is power cycled. I do not know what is 
> happening to the box because there are no logs at the time of crash. Logs 
> start rolling after the reboot. 
>
> journald syncs to disk whenever a log message above LOG_ERR is
> delivered. I am not sure what "crash" is supposed to mean, but are you
> sure that at least one LOG_CRIT/LOG_ALERT/LOG_EMERG message is
> delivered to userspace about that?
>
> I am not sure about that. I just assume if some critical issue is happening 
> such that it makes the system unresponsive, then there should be high 
> priority logs associated with it. 
>
> > > Since the syslog component of systemd, journald, does not flush its
> > > logs to disk during normal operation, these logs will be gone when the
> > > machine is shut down abnormally (power loss, kernel lock-ups, ...). In
> > > the case of kernel lock-ups, it is pretty important to have some
> > > kernel logs for debugging. Until journald gains a configuration option
> > > for flushing kernel logs, rsyslog can be used in conjunction with
> > > journald.
>
> As mentioned above, we wil sync immediately when a
> LOG_CRIT/LOG_ALERT/LOG_EMERG log message is seen. We'll also sync on
> normal log messages with a delay of 5min at max:
>
> 
> https://github.com/systemd/systemd/blob/master/src/journal/journald-server.c#L1440
>  
> 
>
> if you get get a hard kernel lockup for some reason then this all is
> useless however, as userspace won't even get the opportunity to write
> anything to disk then... And it doesn't matter if userspace runs
> journald or rsyslog.
>
>
> So I think one of the following is happening: 
> a) no log is generated at the time of crash (I think this is unlikely) 
> b) log is generated but does not reach journald 
> c) log reaches journald but journald does not get a chance to persist it
> d) journald persists the log but somehow the log is corrupted and ignored
>
> I think scenario "c" is the most probable one in my case. So I just want to 
> confirm if kernel panics, then most probably I will not see any logs in my 
> log files? Is there a recommended workaround to debug such cases? 
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Newer videos

[Mantas Mikulėnas]

On Sun, Jan 21, 2018 at 4:21 PM, Cecil Westerhof 
wrote:
> I wanted to dive deeper into systemd. So I sought videos on YouTube. The
most current I found was:
> https://www.youtube.com/watch?v=S9YmaNuvw5U
>
> But that one is 2½ years old. Is there something more recent? It was
certainly interesting, but it is not completely up-to-date. For example
> /usr/lib/systemd/system
> is now:
> /lib/systemd/system

It is not. That's something your distro has changed.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is it possible to set CPUAffinity at runtime

[Cecil Westerhof]

2018-01-21 17:18 GMT+01:00 Cecil Westerhof :

>
> I would like to change the CPUaffinity of a service at runtime. Is this
> possible?
>

​If it is not possible with a systemd command, it can be done like this:
taskset -cp 3 21234​

​This set the CPUAffinity of process with pid 21234 to cpu3.​

-- 
Cecil Westerhof
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-journald missing crash logs

[Farzad Panahi]

Hi Lennart - Thanks for your comments.

On Mon, Jan 15, 2018 at 4:11 AM, Lennart Poettering 
wrote:

> On Fr, 12.01.18 16:13, Farzad Panahi (farzad.pan...@gmail.com) wrote:
>
> > I am running Arch-ARM on RPi3. I have noticed when system crashes I
> cannot
> > find any related crash log in journal logs.
>
> What specifically is a "crash" supposed to mean?
>
>
Crash in my case means that the box becomes unresponsive. Meaning that I
cannot ssh to it anymore until it is power cycled. I do not know what is
happening to the box because there are no logs at the time of crash. Logs
start rolling after the reboot.

journald syncs to disk whenever a log message above LOG_ERR is
> delivered. I am not sure what "crash" is supposed to mean, but are you
> sure that at least one LOG_CRIT/LOG_ALERT/LOG_EMERG message is
> delivered to userspace about that?
>
> I am not sure about that. I just assume if some critical issue is
happening such that it makes the system unresponsive, then there should be
high priority logs associated with it.

> > Since the syslog component of systemd, journald, does not flush its
> > > logs to disk during normal operation, these logs will be gone when the
> > > machine is shut down abnormally (power loss, kernel lock-ups, ...). In
> > > the case of kernel lock-ups, it is pretty important to have some
> > > kernel logs for debugging. Until journald gains a configuration option
> > > for flushing kernel logs, rsyslog can be used in conjunction with
> > > journald.
>
> As mentioned above, we wil sync immediately when a
> LOG_CRIT/LOG_ALERT/LOG_EMERG log message is seen. We'll also sync on
> normal log messages with a delay of 5min at max:
>
> https://github.com/systemd/systemd/blob/master/src/
> journal/journald-server.c#L1440
>
> if you get get a hard kernel lockup for some reason then this all is
> useless however, as userspace won't even get the opportunity to write
> anything to disk then... And it doesn't matter if userspace runs
> journald or rsyslog.
>
>
So I think one of the following is happening:
a) no log is generated at the time of crash (I think this is unlikely)
b) log is generated but does not reach journald
c) log reaches journald but journald does not get a chance to persist it
d) journald persists the log but somehow the log is corrupted and ignored

I think scenario "c" is the most probable one in my case. So I just want to
confirm if kernel panics, then most probably I will not see any logs in my
log files? Is there a recommended workaround to debug such cases?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Is it possible to set CPUAffinity at runtime

[Cecil Westerhof]

I would like to change the CPUaffinity of a service at runtime. Is this
possible?

-- 
Cecil Westerhof
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] SSL handshake error from offlineimap when using systemd to initialize

[Yubin Ruan]

Hi,

I use offlineimap to synchronize my emails. I want it to do a synchronization
at system startup so recently I add a systemd service for it. However I always
get error like this:

   EOF occurred in violation of protocol (_ssl.c:590)
  *** Finished account 'BLACK' in 0:00
 ERROR: Exceptions occurred during the run!
 ERROR: While attempting to sync account 'BLACK'
   EOF occurred in violation of protocol (_ssl.c:590)
 Traceback:
   File "/usr/share/offlineimap/offlineimap/accounts.py", line 263, in 
syncrunner
 self.__sync()
   File "/usr/share/offlineimap/offlineimap/accounts.py", line 326, in __sync
 remoterepos.getfolders()
   File "/usr/share/offlineimap/offlineimap/repository/IMAP.py", line 384, in 
getfolders
 imapobj = self.imapserver.acquireconnection()
   File "/usr/share/offlineimap/offlineimap/imapserver.py", line 483, in 
acquireconnection
 tls_level=self.tlslevel,
   File "/usr/share/offlineimap/offlineimap/imaplibutil.py", line 186, in 
__init__
 super(WrappedIMAP4_SSL, self).__init__(*args, **kwargs)
   File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 2138, in __init__
 IMAP4.__init__(self, host, port, debug, debug_file, identifier, timeout, 
debug_buf_lvl)
   File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 357, in __init__
 self.open(host, port)
   File "/usr/share/offlineimap/offlineimap/imaplibutil.py", line 194, in open
 super(WrappedIMAP4_SSL, self).open(host, port)
   File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 2151, in open
 self.ssl_wrap_socket()
   File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 522, in 
ssl_wrap_socket
 self.sock = ssl.wrap_socket(self.sock, self.keyfile, self.certfile, 
ca_certs=self.ca_certs, cert_reqs=cert_reqs, ssl_version=ssl_version)
   File "/usr/lib/python2.7/ssl.py", line 933, in wrap_socket
 ciphers=ciphers)
   File "/usr/lib/python2.7/ssl.py", line 601, in __init__
 self.do_handshake()
   File "/usr/lib/python2.7/ssl.py", line 830, in do_handshake
 self._sslobj.do_handshake()

Currently I don't know what the problem is, but:

1. usually (after system startup) the same service is invoked by a timer
and it works well so there is no problem with the script.

2. I believe the network is reachable, because the system will
auto-connect WIFI after system startup. Maybe the initialization order is
not configured properly? If so please see my mail service file below.

I heard that to perform a SSL handshake the system have to contain some
randomness (such that some random keys can be generated), so maybe a SSL
handshake at system startup is deemed to fail?

FYI, this is my systemd mail service file:

# ~/.config/systemd/user/mail.service
# this file is enabled with "systemctl --user enable mail.service
[Unit]
Description=Sync mail
After=network.target

[Service]
Type=oneshot
ExecStart=/path/to/the/script/mmail
TimeoutStartSec=1min30s

[Install]
WantedBy=default.target

--
Yubin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Newer videos

[Cecil Westerhof]

I wanted to dive deeper into systemd. So I sought videos on YouTube. The
most current I found was:
https://www.youtube.com/watch?v=S9YmaNuvw5U

But that one is 2½ years old. Is there something more recent? It was
certainly interesting, but it is not completely up-to-date. For example
/usr/lib/systemd/system
​is now:
/lib/systemd/system
​
​And there are probably a lot of new functionalities.​

-- 
Cecil Westerhof
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to make journald increase logs storage capacity?

[vcaputo]

On Sat, Jan 20, 2018 at 08:28:21PM +0300, 4xy wrote:
> I have limit in 4Gb for journald regardless of the settings I've made. I see
> this line in the manual
> 
> |$ sudo systemctl status systemd-journald ... jan 20 15:44:26 host
> systemd-journald[1218]: System journal (/var/log/journal/) is 4.5G, max
> 4.0G, 0B free. jan 20 15:44:26 host systemd-journald[1218]: Journal started|
> 
> I see this line in the manual.
> 
> > The first pair defaults to 10%  and the second to 15% of the size of the
> > respective file system, but
> each value is capped to 4G.
> 

This is referencing the defaults configured automatically, they're first
computed as a %age, confined to 4G.  The wording of that sentence could
probably be improved in the documentaiton.

> I have about 1Gb logs per day. I would like to have ability to keep them
> about 3 months.
> 

It sounds like you want to keep around 100G of logs:

SystemMaxUse=100G


Note that performance of commands like `journalctl` and even `systemctl
status $unit` drops significantly with large numbers of journals.
As a consequence, you may want to increase the maximum size of the
individual journal files so there are fewer of them:

SystemMaxFileSize=10G

Something like that...

Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel