[systemd-devel] pid 1 memlock setting configurable?

[Kees Bos]

Hi all,

I couldn't find it with google, and before digging in the code just a
quick question. Probably someone knows it in the top of h(is|er)
head...

It seems that systemd drops rlimit_memlock on startup. Correct? And if
so, is it configurable?


Explanation for the question:
In an unprivileged container I can set the memlock config lower than
16MB (16777216 bytes), but not higher. That is, i can configure it, but
effectively the systemd process (pid 1) will never have a limit higher
than 16MB. Since it's an unprivileged container (and thus a fake 'root'
user), that limit also becomes the max for all spawned processes
(including services).

Cheers,

Kees

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

Re: [systemd-devel] Antw: Re: dbus-daemon keep shown as zombie process why ?

[Dorian ROSSE]

I enabled core dump



I follown this link :

https://linux-audit.com/understand-and-configure-core-dumps-work-on-linux/



But do this answer of this command line are good ? :

cat /proc/sys/kernel/core_pattern

/var/crash/core.%u.%e.%p

Thank you in advance to follow the problem,

Regards.


Dorian ROSSE.



Provenance : Courrier pour 
Windows 10




De : Ulrich Windl 
Envoyé : Wednesday, May 22, 2019 3:17:32 PM
À : Dorian ROSSE; Lennart Poettering
Cc : systemd-devel@lists.freedesktop.org
Objet : RE: Antw: Re: [systemd-devel] dbus-daemon keep shown as zombie process 
why ?

Could it be that dbus dies (unexpectedly), and systemd needs dbus to work?
Maybe enabling coredumps could help finding out why dbus quits.

Regards,
Ulrich

>>> Dorian ROSSE  schrieb am 22.05.2019 um 14:03 in
Nachricht


> I have agains dbus‑daemon shown as zombie as Following :
>
> ps aux |grep "defunct"
> root 13349  0.0  0.0  0 0 ?Zs   12:00   0:00
> [dbus‑daemon] 
>
> Regards.
>
>
> Dorian ROSSE.
>
> Provenance : Courrier pour
> Windows 10
>
> 
> De : Dorian ROSSE
> Envoyé : Wednesday, May 22, 2019 12:58:15 PM
> À : Ulrich Windl; Lennart Poettering
> Cc : systemd‑de...@lists.freedesktop.org
> Objet : RE: Antw: Re: [systemd‑devel] dbus‑daemon keep shown as zombie
process
> why ?
>
>
> I launch the command line adviced strace ‑p 1
>
> strace ‑p 1
>
> strace: Process 1 attached
>
> ppoll([{fd=22, events=POLLIN}], 1, {tv_sec=53, tv_nsec=119912101}, NULL, 8
>
> Why I should search a coredump ?
>
> What I must do now ?
>
>
> Now I have my system frozen for update and upgrade :’( ,
>
> Thank you for your time bring for me,
>
> Thank you in advance to help me again,
>
> Regards.
>
>
> Dorian ROSSE.
>
>
>
> Provenance : Courrier pour
> Windows 10
>
>
>
> 
> De : Ulrich Windl 
> Envoyé : Wednesday, May 22, 2019 11:01:37 AM
> À : Dorian ROSSE; Lennart Poettering
> Cc : systemd‑de...@lists.freedesktop.org
> Objet : Antw: Re: [systemd‑devel] dbus‑daemon keep shown as zombie process
why
> ?
>
 Lennart Poettering  schrieb am 22.05.2019 um
10:32
> in
> Nachricht <20190522083211.GB30001@gardel‑login>:
>> On Di, 21.05.19 17:41, Dorian ROSSE (dorianbr...@hotmail.fr) wrote:
>>
>>> Hello everybody,
>>>
>>>
>>> I know this isn’t a bug or a systemd problems but It keeps the
>>> system in thought of dbus‑daemon should be a zombie process but my
>>> web page about zombie process say I should kill the parent but the
>>> parent is systemd lol
>>>
>>> If somebody know Something about this feeling of dbus‑daemon zombie
>>> process,
>>
>> That suggests your system is in a very borked state and PID 1 is frozen
>> and doesn't rip zombies anymore. Look for coredumps in the logs.
>
> An "strace ‑p 1" might also show what's going on. Or examine /proc/1;
SIGCHLD
> might be blocked or ignored.
>
>>
>> Lennart
>>
>> ‑‑
>> Lennart Poettering, Berlin
>> ___
>> systemd‑devel mailing list
>> systemd‑de...@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] Antw: Re: dbus-daemon keep shown as zombie process why ?

[Dorian ROSSE]

No It failed :

ulimit -S -c dbus-daemon

-bash: ulimit: dbus-daemon: invalid number



Provenance : Courrier pour 
Windows 10




De : Ulrich Windl 
Envoyé : Wednesday, May 22, 2019 3:17:32 PM
À : Dorian ROSSE; Lennart Poettering
Cc : systemd-devel@lists.freedesktop.org
Objet : RE: Antw: Re: [systemd-devel] dbus-daemon keep shown as zombie process 
why ?

Could it be that dbus dies (unexpectedly), and systemd needs dbus to work?
Maybe enabling coredumps could help finding out why dbus quits.

Regards,
Ulrich

>>> Dorian ROSSE  schrieb am 22.05.2019 um 14:03 in
Nachricht


> I have agains dbus‑daemon shown as zombie as Following :
>
> ps aux |grep "defunct"
> root 13349  0.0  0.0  0 0 ?Zs   12:00   0:00
> [dbus‑daemon] 
>
> Regards.
>
>
> Dorian ROSSE.
>
> Provenance : Courrier pour
> Windows 10
>
> 
> De : Dorian ROSSE
> Envoyé : Wednesday, May 22, 2019 12:58:15 PM
> À : Ulrich Windl; Lennart Poettering
> Cc : systemd‑de...@lists.freedesktop.org
> Objet : RE: Antw: Re: [systemd‑devel] dbus‑daemon keep shown as zombie
process
> why ?
>
>
> I launch the command line adviced strace ‑p 1
>
> strace ‑p 1
>
> strace: Process 1 attached
>
> ppoll([{fd=22, events=POLLIN}], 1, {tv_sec=53, tv_nsec=119912101}, NULL, 8
>
> Why I should search a coredump ?
>
> What I must do now ?
>
>
> Now I have my system frozen for update and upgrade :’( ,
>
> Thank you for your time bring for me,
>
> Thank you in advance to help me again,
>
> Regards.
>
>
> Dorian ROSSE.
>
>
>
> Provenance : Courrier pour
> Windows 10
>
>
>
> 
> De : Ulrich Windl 
> Envoyé : Wednesday, May 22, 2019 11:01:37 AM
> À : Dorian ROSSE; Lennart Poettering
> Cc : systemd‑de...@lists.freedesktop.org
> Objet : Antw: Re: [systemd‑devel] dbus‑daemon keep shown as zombie process
why
> ?
>
 Lennart Poettering  schrieb am 22.05.2019 um
10:32
> in
> Nachricht <20190522083211.GB30001@gardel‑login>:
>> On Di, 21.05.19 17:41, Dorian ROSSE (dorianbr...@hotmail.fr) wrote:
>>
>>> Hello everybody,
>>>
>>>
>>> I know this isn’t a bug or a systemd problems but It keeps the
>>> system in thought of dbus‑daemon should be a zombie process but my
>>> web page about zombie process say I should kill the parent but the
>>> parent is systemd lol
>>>
>>> If somebody know Something about this feeling of dbus‑daemon zombie
>>> process,
>>
>> That suggests your system is in a very borked state and PID 1 is frozen
>> and doesn't rip zombies anymore. Look for coredumps in the logs.
>
> An "strace ‑p 1" might also show what's going on. Or examine /proc/1;
SIGCHLD
> might be blocked or ignored.
>
>>
>> Lennart
>>
>> ‑‑
>> Lennart Poettering, Berlin
>> ___
>> systemd‑devel mailing list
>> systemd‑de...@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] Antw: Re: dbus-daemon keep shown as zombie process why ?

[Dorian ROSSE]

I enabled core dump for dbus





Provenance : Courrier pour 
Windows 10




De : Ulrich Windl 
Envoyé : Wednesday, May 22, 2019 3:17:32 PM
À : Dorian ROSSE; Lennart Poettering
Cc : systemd-devel@lists.freedesktop.org
Objet : RE: Antw: Re: [systemd-devel] dbus-daemon keep shown as zombie process 
why ?

Could it be that dbus dies (unexpectedly), and systemd needs dbus to work?
Maybe enabling coredumps could help finding out why dbus quits.

Regards,
Ulrich

>>> Dorian ROSSE  schrieb am 22.05.2019 um 14:03 in
Nachricht


> I have agains dbus‑daemon shown as zombie as Following :
>
> ps aux |grep "defunct"
> root 13349  0.0  0.0  0 0 ?Zs   12:00   0:00
> [dbus‑daemon] 
>
> Regards.
>
>
> Dorian ROSSE.
>
> Provenance : Courrier pour
> Windows 10
>
> 
> De : Dorian ROSSE
> Envoyé : Wednesday, May 22, 2019 12:58:15 PM
> À : Ulrich Windl; Lennart Poettering
> Cc : systemd‑de...@lists.freedesktop.org
> Objet : RE: Antw: Re: [systemd‑devel] dbus‑daemon keep shown as zombie
process
> why ?
>
>
> I launch the command line adviced strace ‑p 1
>
> strace ‑p 1
>
> strace: Process 1 attached
>
> ppoll([{fd=22, events=POLLIN}], 1, {tv_sec=53, tv_nsec=119912101}, NULL, 8
>
> Why I should search a coredump ?
>
> What I must do now ?
>
>
> Now I have my system frozen for update and upgrade :’( ,
>
> Thank you for your time bring for me,
>
> Thank you in advance to help me again,
>
> Regards.
>
>
> Dorian ROSSE.
>
>
>
> Provenance : Courrier pour
> Windows 10
>
>
>
> 
> De : Ulrich Windl 
> Envoyé : Wednesday, May 22, 2019 11:01:37 AM
> À : Dorian ROSSE; Lennart Poettering
> Cc : systemd‑de...@lists.freedesktop.org
> Objet : Antw: Re: [systemd‑devel] dbus‑daemon keep shown as zombie process
why
> ?
>
 Lennart Poettering  schrieb am 22.05.2019 um
10:32
> in
> Nachricht <20190522083211.GB30001@gardel‑login>:
>> On Di, 21.05.19 17:41, Dorian ROSSE (dorianbr...@hotmail.fr) wrote:
>>
>>> Hello everybody,
>>>
>>>
>>> I know this isn’t a bug or a systemd problems but It keeps the
>>> system in thought of dbus‑daemon should be a zombie process but my
>>> web page about zombie process say I should kill the parent but the
>>> parent is systemd lol
>>>
>>> If somebody know Something about this feeling of dbus‑daemon zombie
>>> process,
>>
>> That suggests your system is in a very borked state and PID 1 is frozen
>> and doesn't rip zombies anymore. Look for coredumps in the logs.
>
> An "strace ‑p 1" might also show what's going on. Or examine /proc/1;
SIGCHLD
> might be blocked or ignored.
>
>>
>> Lennart
>>
>> ‑‑
>> Lennart Poettering, Berlin
>> ___
>> systemd‑devel mailing list
>> systemd‑de...@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] Antw: Re: dbus-daemon keep shown as zombie process why ?

[Ulrich Windl]

Could it be that dbus dies (unexpectedly), and systemd needs dbus to work?
Maybe enabling coredumps could help finding out why dbus quits.

Regards,
Ulrich

>>> Dorian ROSSE  schrieb am 22.05.2019 um 14:03 in
Nachricht


> I have agains dbus‑daemon shown as zombie as Following :
> 
> ps aux |grep "defunct"
> root 13349  0.0  0.0  0 0 ?Zs   12:00   0:00 
> [dbus‑daemon] 
> 
> Regards.
> 
> 
> Dorian ROSSE.
> 
> Provenance : Courrier pour 
> Windows 10
> 
> 
> De : Dorian ROSSE
> Envoyé : Wednesday, May 22, 2019 12:58:15 PM
> À : Ulrich Windl; Lennart Poettering
> Cc : systemd‑de...@lists.freedesktop.org 
> Objet : RE: Antw: Re: [systemd‑devel] dbus‑daemon keep shown as zombie
process 
> why ?
> 
> 
> I launch the command line adviced strace ‑p 1
> 
> strace ‑p 1
> 
> strace: Process 1 attached
> 
> ppoll([{fd=22, events=POLLIN}], 1, {tv_sec=53, tv_nsec=119912101}, NULL, 8
> 
> Why I should search a coredump ?
> 
> What I must do now ?
> 
> 
> Now I have my system frozen for update and upgrade :’( ,
> 
> Thank you for your time bring for me,
> 
> Thank you in advance to help me again,
> 
> Regards.
> 
> 
> Dorian ROSSE.
> 
> 
> 
> Provenance : Courrier pour 
> Windows 10
> 
> 
> 
> 
> De : Ulrich Windl 
> Envoyé : Wednesday, May 22, 2019 11:01:37 AM
> À : Dorian ROSSE; Lennart Poettering
> Cc : systemd‑de...@lists.freedesktop.org 
> Objet : Antw: Re: [systemd‑devel] dbus‑daemon keep shown as zombie process
why 
> ?
> 
 Lennart Poettering  schrieb am 22.05.2019 um
10:32
> in
> Nachricht <20190522083211.GB30001@gardel‑login>:
>> On Di, 21.05.19 17:41, Dorian ROSSE (dorianbr...@hotmail.fr) wrote:
>>
>>> Hello everybody,
>>>
>>>
>>> I know this isn’t a bug or a systemd problems but It keeps the
>>> system in thought of dbus‑daemon should be a zombie process but my
>>> web page about zombie process say I should kill the parent but the
>>> parent is systemd lol
>>>
>>> If somebody know Something about this feeling of dbus‑daemon zombie
>>> process,
>>
>> That suggests your system is in a very borked state and PID 1 is frozen
>> and doesn't rip zombies anymore. Look for coredumps in the logs.
> 
> An "strace ‑p 1" might also show what's going on. Or examine /proc/1;
SIGCHLD
> might be blocked or ignored.
> 
>>
>> Lennart
>>
>> ‑‑
>> Lennart Poettering, Berlin
>> ___
>> systemd‑devel mailing list
>> systemd‑de...@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] [PATCH] man: systemd-nspawn: Update syntax to launch an image

[Lennart Poettering]

On Mo, 20.05.19 17:08, Kashyap Chamarthy (kcham...@redhat.com) wrote:

> To access a shell on a disk image, the man page on Fedora-29 says to
> run: `systemd-nspawn -M Fedora-Cloud-Base-28-1.1.x86_64.raw`.  Let's
> try.
>
> List existing images:
>
> $> machinectl list-images | awk '{print $1,$2}';
> NAME TYPE
> Fedora-Cloud-Base-30… raw
>
> 1 images
>
> Now invoke `systemd-nspawn` as noted in the man page:
>
> $> systemd-nspawn -M Fedora-Cloud-Base-30-1.2.x86_64.raw
> No image for machine 'Fedora-Cloud-Base-30-1.2.x86_64.raw'.
>
> Removing the ".raw" extension launches the image and gives a shell.
> Update the man page to reflect that.
>
> Frantisek Sumsal on #systemd (Freenode) noted the reason: "In older
> versions systemd -M accepted both image-name.raw and image-name as a
> valid image names, however, on Fedora 29 (systemd-239) with all the
> BTRFS stuff around it accepts only -M image-name (without the
> extension)"

Forwarded to github:

https://github.com/systemd/systemd/pull/12640

Lennart

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

Re: [systemd-devel] Antw: Re: dbus-daemon keep shown as zombie process why ?

[Dorian ROSSE]

I have agains dbus-daemon shown as zombie as Following :

ps aux |grep "defunct"
root 13349  0.0  0.0  0 0 ?Zs   12:00   0:00 [dbus-daemon] 


Regards.


Dorian ROSSE.

Provenance : Courrier pour 
Windows 10


De : Dorian ROSSE
Envoyé : Wednesday, May 22, 2019 12:58:15 PM
À : Ulrich Windl; Lennart Poettering
Cc : systemd-devel@lists.freedesktop.org
Objet : RE: Antw: Re: [systemd-devel] dbus-daemon keep shown as zombie process 
why ?


I launch the command line adviced strace -p 1

strace -p 1

strace: Process 1 attached

ppoll([{fd=22, events=POLLIN}], 1, {tv_sec=53, tv_nsec=119912101}, NULL, 8

Why I should search a coredump ?

What I must do now ?


Now I have my system frozen for update and upgrade :’( ,

Thank you for your time bring for me,

Thank you in advance to help me again,

Regards.


Dorian ROSSE.



Provenance : Courrier pour 
Windows 10




De : Ulrich Windl 
Envoyé : Wednesday, May 22, 2019 11:01:37 AM
À : Dorian ROSSE; Lennart Poettering
Cc : systemd-devel@lists.freedesktop.org
Objet : Antw: Re: [systemd-devel] dbus-daemon keep shown as zombie process why ?

>>> Lennart Poettering  schrieb am 22.05.2019 um 10:32
in
Nachricht <20190522083211.GB30001@gardel-login>:
> On Di, 21.05.19 17:41, Dorian ROSSE (dorianbr...@hotmail.fr) wrote:
>
>> Hello everybody,
>>
>>
>> I know this isn’t a bug or a systemd problems but It keeps the
>> system in thought of dbus-daemon should be a zombie process but my
>> web page about zombie process say I should kill the parent but the
>> parent is systemd lol
>>
>> If somebody know Something about this feeling of dbus-daemon zombie
>> process,
>
> That suggests your system is in a very borked state and PID 1 is frozen
> and doesn't rip zombies anymore. Look for coredumps in the logs.

An "strace -p 1" might also show what's going on. Or examine /proc/1; SIGCHLD
might be blocked or ignored.

>
> Lennart
>
> --
> Lennart Poettering, Berlin
> ___
> 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] Antw: Re: dbus-daemon keep shown as zombie process why ?

[Dorian ROSSE]

I launch the command line adviced strace -p 1

strace -p 1

strace: Process 1 attached

ppoll([{fd=22, events=POLLIN}], 1, {tv_sec=53, tv_nsec=119912101}, NULL, 8

Why I should search a coredump ?

What I must do now ?


Now I have my system frozen for update and upgrade :’( ,

Thank you for your time bring for me,

Thank you in advance to help me again,

Regards.


Dorian ROSSE.



Provenance : Courrier pour 
Windows 10




De : Ulrich Windl 
Envoyé : Wednesday, May 22, 2019 11:01:37 AM
À : Dorian ROSSE; Lennart Poettering
Cc : systemd-devel@lists.freedesktop.org
Objet : Antw: Re: [systemd-devel] dbus-daemon keep shown as zombie process why ?

>>> Lennart Poettering  schrieb am 22.05.2019 um 10:32
in
Nachricht <20190522083211.GB30001@gardel-login>:
> On Di, 21.05.19 17:41, Dorian ROSSE (dorianbr...@hotmail.fr) wrote:
>
>> Hello everybody,
>>
>>
>> I know this isn’t a bug or a systemd problems but It keeps the
>> system in thought of dbus-daemon should be a zombie process but my
>> web page about zombie process say I should kill the parent but the
>> parent is systemd lol
>>
>> If somebody know Something about this feeling of dbus-daemon zombie
>> process,
>
> That suggests your system is in a very borked state and PID 1 is frozen
> and doesn't rip zombies anymore. Look for coredumps in the logs.

An "strace -p 1" might also show what's going on. Or examine /proc/1; SIGCHLD
might be blocked or ignored.

>
> Lennart
>
> --
> Lennart Poettering, Berlin
> ___
> 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] Antw: Re: systemd-tmpfiles-setup.service failed due to LDAP resolving

[Mantas Mikulėnas]

On Wed, May 22, 2019 at 12:52 PM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Lennart Poettering  schrieb am 22.05.2019 um
> 10:30
> in
> Nachricht <20190522083028.GA30001@gardel-login>:
> > On Mi, 22.05.19 10:02, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
> >
> >> Hi!
> >>
> >> Obviously the owner of a temporary directory cannot be an LDAP user:
> >
> > system users should really not be located on LDAP:
>
> OK, but it's a challenge to keep the UIDs in sync on multiple hosts for
> local
> users.
>

I would suggest managing service accounts either via
Salt/Chef/Puppet/Ansible (all of which support creating /etc/passwd
accounts) or via centrally deployed systemd-sysusers.d files (e.g. if you
already have your own file distribution mechanism).

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

Re: [systemd-devel] systemd-tmpfiles-setup.service failed due to LDAP resolving

[Mantas Mikulėnas]

On Wed, May 22, 2019 at 11:30 AM Lennart Poettering 
wrote:

> On Mi, 22.05.19 10:02, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de)
> wrote:
>
> > Hi!
> >
> > Obviously the owner of a temporary directory cannot be an LDAP user:
>
> system users should really not be located on LDAP:
>
>
> https://systemd.io/UIDS-GIDS.html#notes-on-resolvability-of-user-and-group-names
>
> > May 22 09:02:48 v04 systemd-tmpfiles[1056]: nss-ldap: do_open:
> do_start_tls
> > failed:stat=-1
> > May 22 09:02:48 v04 systemd-tmpfiles[1056]: nss_ldap: could not search
> LDAP
> > server - Server is unavailable
> > May 22 09:02:48 v04 systemd[1]: systemd-tmpfiles-setup.service: Main
> process
> > exited, code=exited, status=1/FAILURE
>
> Hmm, we actually log about all errors we encounter. Is it possible
> that the nss-ldap module (which iirc is obsolete and unmaintained
> these days?) does an exit(1) or so?
>

AFAIK, it is indeed obsolete (in favor of either SSSD or the *other*
nss-ldap which comes with nslcd, both of which use a daemon to handle
lookups).

Actually, if LDAP accounts in tmpfiles are somehow unavoidable, then SSSD
may work better as it has a persistent local cache... (Still a bad idea
though, as tmpfiles usually starts before SSSD.)

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

[systemd-devel] Antw: Re: systemd-tmpfiles-setup.service failed due to LDAP resolving

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 22.05.2019 um 10:30
in
Nachricht <20190522083028.GA30001@gardel-login>:
> On Mi, 22.05.19 10:02, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> Obviously the owner of a temporary directory cannot be an LDAP user:
> 
> system users should really not be located on LDAP:

OK, but it's a challenge to keep the UIDs in sync on multiple hosts for local
users.

> 
>
https://systemd.io/UIDS‑GIDS.html#notes‑on‑resolvability‑of‑user‑and‑group‑names

> 
>> May 22 09:02:48 v04 systemd‑tmpfiles[1056]: nss‑ldap: do_open:
do_start_tls
>> failed:stat=‑1
>> May 22 09:02:48 v04 systemd‑tmpfiles[1056]: nss_ldap: could not search
LDAP
>> server ‑ Server is unavailable
>> May 22 09:02:48 v04 systemd[1]: systemd‑tmpfiles‑setup.service: Main
process
>> exited, code=exited, status=1/FAILURE
> 
> Hmm, we actually log about all errors we encounter. Is it possible
> that the nss‑ldap module (which iirc is obsolete and unmaintained
> these days?) does an exit(1) or so?

It seems I had overlooked the message (maybe because "systemd-tmpfiles:
nss-ldap: do_open: do_start_tls failed:stat=-1" continue after the last
error):
systemd-tmpfiles[3051]: [/usr/lib/tmpfiles.d/FCmonitor.conf:1] Unknown group
'nagios'.

> 
> Either way, if we receive an error from NSS and don't log about it,
> that'd be a bug, but please confirm with a current systemd version, or
> contact your downstream who will do that and then propagate this to
> us.
> 
> You can also set the "SYSTEMD_LOG_LEVEL=debug" env var to get more
> detailed output. i.e. use "systemctl edit systemd‑tmpfiles.service",
> then type in:
> 
> [Service]
> Environment=SYSTEMD_LOG_LEVEL=debug
> 
> then save and reboot.
> 
>> The basic problem is that LDAP needs network (which isn't up at this
point).
>> But still, it's hard to tell from the logged messages which entry actually
>> caused the problem. From what I see "root" is the only user being used,
and
>> that user is local in /etc/passwd. /etc/nsswitch.conf has "passwd: 
> compat"...
>>
>> I can create the missing directories later running "systemctl start
>> systemd‑tmpfiles‑setup", but SLES has:
>> /usr/lib/tmpfiles.d/systemd‑nologin.conf:F! /run/nologin 0644 ‑ ‑ ‑ "System
is
>> booting up. See pam_nologin(8)"
>>
>> Which effectively locks out users when doing so.
> 
> You can invoke the binary from shell prompt:
> 
>systemd‑tmpfiles ‑‑create ‑‑clean ‑‑remove
> 
> If you don't specify ‑‑boot then lines like the /run/nologin one won't
> be honoured.

OK, my solution was to "rm /run/nologin".

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



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

Re: [systemd-devel] interacting with logind to detect user idle time

[Germano Massullo]

Il giorno mer 22 mag 2019 alle ore 11:41 Mantas Mikulėnas
 ha scritto:
> On Wed, May 22, 2019, 12:37 Germano Massullo  
> wrote:
>> Second question: perhaps can be useful if I start a topic in GNOME /
>> KDE Plasma development mailing lists asking them to make patches that
>> will let systemd-logind know about user idle time. By doing this,
>> Linux distro world could use systemd-logind as single solution for
>> detecting user idle time, making easier the work of third party
>> developers
>
> Hmm, doesn't GNOME 3 already do this?

Seem to not doing it because the properties
IdleSinceHint
IdleSinceHintMonotonic
are always equal to zero even on GNOME 3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] interacting with logind to detect user idle time

[Mantas Mikulėnas]

On Wed, May 22, 2019, 12:37 Germano Massullo 
wrote:

> Il giorno mer 22 mag 2019 alle ore 11:17 Mantas Mikulėnas
>  ha scritto:
> > If your program is already X11-based, you could use the screensaver
> protocol to get idle status and forward it to logind.
>
> BOINC client is just a service, and it runs on machines that can run
> X11, Wayland, or no graphical session.
> So if with screensaver protocol you meant XScreensaver API, this
> unfortunately will not fit my needs. Perhaps instead of using a single
> solution for all of them I have to write some code that will adapt at
> least to the main desktop environments, by asking to them the user
> idle time.
>

Better to have a small 'agent' program that runs within the desktop
environment and reports idleness to logind like the DE is supposed to.

That program would be able to use X11 to determine session idleness, and
it'd work for all DEs and wouldn't be limited to BOINC either.

Having BOINC itself dig into the internals of every DE is ... not optimal.


> Second question: perhaps can be useful if I start a topic in GNOME /
> KDE Plasma development mailing lists asking them to make patches that
> will let systemd-logind know about user idle time. By doing this,
> Linux distro world could use systemd-logind as single solution for
> detecting user idle time, making easier the work of third party
> developers
>

Hmm, doesn't GNOME 3 already do this?


___
> 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] interacting with logind to detect user idle time

[Germano Massullo]

Il giorno mer 22 mag 2019 alle ore 11:17 Mantas Mikulėnas
 ha scritto:
> If your program is already X11-based, you could use the screensaver protocol 
> to get idle status and forward it to logind.

BOINC client is just a service, and it runs on machines that can run
X11, Wayland, or no graphical session.
So if with screensaver protocol you meant XScreensaver API, this
unfortunately will not fit my needs. Perhaps instead of using a single
solution for all of them I have to write some code that will adapt at
least to the main desktop environments, by asking to them the user
idle time.

Second question: perhaps can be useful if I start a topic in GNOME /
KDE Plasma development mailing lists asking them to make patches that
will let systemd-logind know about user idle time. By doing this,
Linux distro world could use systemd-logind as single solution for
detecting user idle time, making easier the work of third party
developers
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] interacting with logind to detect user idle time

[Mantas Mikulėnas]

On Wed, May 22, 2019, 12:13 Germano Massullo 
wrote:

> Good day.
> I have noticed that on many Linux distributions with different desktop
> environments, the properties
> IdleSinceHint
> IdleSinceHintMonotonic
> are always equal to zero. This happens even if you try to use a sleep
> in order to simulate a kind of user inactivity.
> What is this happening?
>

Those desktop environments just do not set the IdleHint at all.

(Logind on its own cannot determine idleness "from the outside", it relies
on the DE to pass this information.)

If your program is already X11-based, you could use the screensaver
protocol to get idle status and forward it to logind.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] interacting with logind to detect user idle time

[Germano Massullo]

Good day.
I have noticed that on many Linux distributions with different desktop
environments, the properties
IdleSinceHint
IdleSinceHintMonotonic
are always equal to zero. This happens even if you try to use a sleep
in order to simulate a kind of user inactivity.
What is this happening?
I have written a little piece of code that is able to print on
standard output the IdleSinceHint

Thank you!
/*
 * Compile with:
 *   gcc -Wall print_user_idle_time.c -o print_user_idle_time `pkg-config --libs gio-2.0 --cflags`
 */

#include 

static void
print_user_idle_time (GDBusProxy *proxy)
{
guint64 user_idle_time;
gchar *property = "IdleSinceHint";
	GError *error = NULL;
	GVariant *ret = NULL;

sleep(2);

	ret = g_dbus_proxy_get_cached_property(proxy, property);
	if (!ret) {
		g_dbus_error_strip_remote_error (error);
		g_print ("IdleSinceHint failed: %s\n", error->message);
		g_error_free (error);
		return;
	}

	user_idle_time = g_variant_get_uint64 (ret);
/*
	/g_variant_get (ret, "(^ao)", _idle_time);
	has been replaced with
	user_idle_time = g_variant_get_uint64 (ret);
	*/
	g_print("%lu\n", user_idle_time);
g_variant_unref (ret);
}

int
main (int argc, char *argv[])
{
	GDBusProxy *proxy = NULL;
gchar *name = "org.freedesktop.login1";
gchar *object_path = "/org/freedesktop/login1";
gchar *interface_name = "org.freedesktop.login1.Manager";
	/* Create a D-Bus proxy */
	proxy = g_dbus_proxy_new_for_bus_sync (G_BUS_TYPE_SYSTEM,
	   G_DBUS_PROXY_FLAGS_NONE,
	   NULL,
	   name,
	   object_path,
	   interface_name,
	   NULL, NULL);
	g_assert (proxy != NULL);

	print_user_idle_time (proxy);

	g_object_unref (proxy);

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

[systemd-devel] Antw: Re: Failed to open system journal: Invalid argument

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 22.05.2019 um 10:34 
>>> in
Nachricht <20190522083459.GC30001@gardel-login>:
> On Mi, 22.05.19 01:03, Kay One (kayone...@gmail.com) wrote:
> 
>> Hi Lennart,
>>
>> Do you have any idea that UBIFS supports writable memory mappings or
>> not?
> 
> No idea, sorry!
> 
> This suggests that UBIFS treats mmap like any other fs would, and thus
> probably also supports mmap() just fine in writable mode and everything:
> 
> https://yaffs.net/lurker/message/20100616.081709.b6153097.en.html 


MHO: While any filesystem can in principle support mmap(), it only makes sense 
for filesystems that support sparse files. At least in general that's the 
expectation of using mmap() writes. Otherwise things may be unexpectedly slow 
(map a gig on such a filesystem, then write the last block)...

> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> ___
> 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

[systemd-devel] Antw: Re: dbus-daemon keep shown as zombie process why ?

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 22.05.2019 um 10:32
in
Nachricht <20190522083211.GB30001@gardel-login>:
> On Di, 21.05.19 17:41, Dorian ROSSE (dorianbr...@hotmail.fr) wrote:
> 
>> Hello everybody,
>>
>>
>> I know this isn’t a bug or a systemd problems but It keeps the
>> system in thought of dbus-daemon should be a zombie process but my
>> web page about zombie process say I should kill the parent but the
>> parent is systemd lol
>>
>> If somebody know Something about this feeling of dbus-daemon zombie
>> process,
> 
> That suggests your system is in a very borked state and PID 1 is frozen
> and doesn't rip zombies anymore. Look for coredumps in the logs.

An "strace -p 1" might also show what's going on. Or examine /proc/1; SIGCHLD
might be blocked or ignored.

> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> ___
> 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] Failed to open system journal: Invalid argument

[Lennart Poettering]

On Mi, 22.05.19 01:03, Kay One (kayone...@gmail.com) wrote:

> Hi Lennart,
>
> Do you have any idea that UBIFS supports writable memory mappings or
> not?

No idea, sorry!

This suggests that UBIFS treats mmap like any other fs would, and thus
probably also supports mmap() just fine in writable mode and everything:

https://yaffs.net/lurker/message/20100616.081709.b6153097.en.html

Lennart

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

Re: [systemd-devel] dbus-daemon keep shown as zombie process why ?

[Lennart Poettering]

On Di, 21.05.19 17:41, Dorian ROSSE (dorianbr...@hotmail.fr) wrote:

> Hello everybody,
>
>
> I know this isn’t a bug or a systemd problems but It keeps the
> system in thought of dbus-daemon should be a zombie process but my
> web page about zombie process say I should kill the parent but the
> parent is systemd lol
>
> If somebody know Something about this feeling of dbus-daemon zombie
> process,

That suggests your system is in a very borked state and PID 1 is frozen
and doesn't rip zombies anymore. Look for coredumps in the logs.

Lennart

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

Re: [systemd-devel] systemd-tmpfiles-setup.service failed due to LDAP resolving

[Lennart Poettering]

On Mi, 22.05.19 10:02, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> Hi!
>
> Obviously the owner of a temporary directory cannot be an LDAP user:

system users should really not be located on LDAP:

https://systemd.io/UIDS-GIDS.html#notes-on-resolvability-of-user-and-group-names

> May 22 09:02:48 v04 systemd-tmpfiles[1056]: nss-ldap: do_open: do_start_tls
> failed:stat=-1
> May 22 09:02:48 v04 systemd-tmpfiles[1056]: nss_ldap: could not search LDAP
> server - Server is unavailable
> May 22 09:02:48 v04 systemd[1]: systemd-tmpfiles-setup.service: Main process
> exited, code=exited, status=1/FAILURE

Hmm, we actually log about all errors we encounter. Is it possible
that the nss-ldap module (which iirc is obsolete and unmaintained
these days?) does an exit(1) or so?

Either way, if we receive an error from NSS and don't log about it,
that'd be a bug, but please confirm with a current systemd version, or
contact your downstream who will do that and then propagate this to
us.

You can also set the "SYSTEMD_LOG_LEVEL=debug" env var to get more
detailed output. i.e. use "systemctl edit systemd-tmpfiles.service",
then type in:

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

then save and reboot.

> The basic problem is that LDAP needs network (which isn't up at this point).
> But still, it's hard to tell from the logged messages which entry actually
> caused the problem. From what I see "root" is the only user being used, and
> that user is local in /etc/passwd. /etc/nsswitch.conf has "passwd: compat"...
>
> I can create the missing directories later running "systemctl start
> systemd-tmpfiles-setup", but SLES has:
> /usr/lib/tmpfiles.d/systemd-nologin.conf:F! /run/nologin 0644 - - - "System is
> booting up. See pam_nologin(8)"
>
> Which effectively locks out users when doing so.

You can invoke the binary from shell prompt:

   systemd-tmpfiles --create --clean --remove

If you don't specify --boot then lines like the /run/nologin one won't
be honoured.

Lennart

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

[systemd-devel] systemd-tmpfiles-setup.service failed due to LDAP resolving

[Ulrich Windl]

Hi!

Obviously the owner of a temporary directory cannot be an LDAP user:
# systemctl status systemd-tmpfiles-setup -l
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
   Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service;
static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2019-05-22 09:02:48 CEST;
46min ago
 Docs: man:tmpfiles.d(5)
   man:systemd-tmpfiles(8)
  Process: 1056 ExecStart=/usr/bin/systemd-tmpfiles --create --remove --boot
--exclude-prefix=/dev (code=exited, status=1/FAILURE)
 Main PID: 1056 (code=exited, status=1/FAILURE)

May 22 09:02:48 v04 systemd-tmpfiles[1056]: nss-ldap: do_open: do_start_tls
failed:stat=-1
May 22 09:02:48 v04 systemd-tmpfiles[1056]: nss-ldap: do_open: do_start_tls
failed:stat=-1
May 22 09:02:48 v04 systemd-tmpfiles[1056]: nss-ldap: do_open: do_start_tls
failed:stat=-1
May 22 09:02:48 v04 systemd-tmpfiles[1056]: nss-ldap: do_open: do_start_tls
failed:stat=-1
May 22 09:02:48 v04 systemd-tmpfiles[1056]: nss-ldap: do_open: do_start_tls
failed:stat=-1
May 22 09:02:48 v04 systemd-tmpfiles[1056]: nss_ldap: could not search LDAP
server - Server is unavailable
May 22 09:02:48 v04 systemd[1]: systemd-tmpfiles-setup.service: Main process
exited, code=exited, status=1/FAILURE
May 22 09:02:48 v04 systemd[1]: Failed to start Create Volatile Files and
Directories.
May 22 09:02:48 v04 systemd[1]: systemd-tmpfiles-setup.service: Unit entered
failed state.
May 22 09:02:48 v04 systemd[1]: systemd-tmpfiles-setup.service: Failed with
result 'exit-code'.

The basic problem is that LDAP needs network (which isn't up at this point).
But still, it's hard to tell from the logged messages which entry actually
caused the problem. From what I see "root" is the only user being used, and
that user is local in /etc/passwd. /etc/nsswitch.conf has "passwd: compat"...

I can create the missing directories later running "systemctl start
systemd-tmpfiles-setup", but SLES has:
/usr/lib/tmpfiles.d/systemd-nologin.conf:F! /run/nologin 0644 - - - "System is
booting up. See pam_nologin(8)"

Which effectively locks out users when doing so.

Any splendid ideas?

Regards,
Ulrich



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