[systemd-devel] dirsrv fails to start

[Chris Justice]

Hi All,

Everything has been working great until now.  Suddonly one of our IDM
servers is no longer able to start IPA services.  We keep running into an
issue with Dirsrv failing to start " see logs below"
( replaced domain name with  for privacy )
Unit dirsrv@.service has failed.
-- 
-- The result is failed.
Jun 11 09:01:41 den02vmidm01. systemd[1]: Unit dirsrv@.service
entered failed state.
Jun 11 09:01:41 den02vmidm01. systemd[1]: dirsrv@.service failed.
Jun 11 09:01:41 den02vmidm01. ipactl[22865]: Failed to start Directory
Service: Command '/bin/systemctl start dirsrv@.service' returned
non-zero exit status 1
Jun 11 09:01:41 den02vmidm01. ipactl[22865]: Starting Directory Service
Jun 11 09:01:41 den02vmidm01. systemd[1]: ipa.service: main process
exited, code=exited, status=1/FAILURE
Jun 11 09:01:41 den02vmidm01. systemd[1]: Failed to start Identity,
Policy, Audit.
-- Subject: Unit ipa.service has failed



Any help would greatly be appreciated as this is starting to effect some
production info
-- 

*Chris Justice*

*System Administrator | Zayo Group *

*4500 S 129th East Ave Tulsa, OK 74134*

*Desk: 918.901.9159 | Cell: 918.619.5432*

chris.just...@zayo.com 
Mission  | Network Map
 | LinkedIn
 | Twitter

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

Re: [systemd-devel] coredump missing in systemd

[Dorian ROSSE]

Where are coredump now :

systemctl status systemd-coredump.socket
Failed to dump process list, ignoring: No such file or directory
● systemd-coredump.socket - Process Core Dump Socket
   Loaded: loaded (/lib/systemd/system/systemd-coredump.socket; static; vendor 
preset: enabled)
   Active: active (listening) since Mon 2019-06-10 12:40:03 UTC; 22h ago

It is under listening It went to rotate logs

I think success to dump dbus-daemon

Regards.


Dorian ROSSE.

Provenance : Courrier pour 
Windows 10


De : Ryan Gonzalez 
Envoyé : Saturday, May 25, 2019 6:32:17 AM
À : systemd Mailing List; Dorian ROSSE
Objet : RE: [systemd-devel] coredump missing in systemd

Ah you must be on an older systemd version, try 'coredumpctl gdb dbus-daemon'.

-- Ryan
https://refi64.com/
On May 24, 2019, 4:42 AM -0500, Dorian ROSSE , wrote:
coredumpctl debug dbus-daemon
Unknown action 'debug'

Anybody has a repair ?

Thank you in advance,

Regards.

(I think I will ask to coredump mailling list if you think It boring)


Dorian ROSSE.

Provenance : Courrier pour 
Windows 10


De : Ryan Gonzalez 
Envoyé : Friday, May 24, 2019 5:28:12 AM
À : systemd Mailing List; Dorian ROSSE
Objet : Re: [systemd-devel] coredump missing in systemd

coredumpctl debug dbus-daemon

assuming it already crashed. M

-- Ryan
https://refi64.com/
On May 23, 2019, 12:16 PM -0500, Dorian ROSSE , wrote:
Hello everybody,


I went to follow this link : https://wiki.archlinux.org/index.php/Core_dump

I readen also coredump is missing for systemd,

How to install core dump ?

Because I can’t use gdb for dbus-daemon as Following :

(gdb) generate-core-file
You can't do that without a process to debug.

pgrep -f dbus-daemon
31873
root@bitfenix-server:/etc/systemd# gdb -p 31873
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 31873
ptrace: No such process.
(gdb) generate-core-file 31873
You can't do that without a process to debug.

Thank you in advance to help me which coredump,

Regards.


Dorian ROSSE.
Provenance : Courrier pour 
Windows 10

___
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: Q: Implementing logrotate's postrotate with systemd

[Michael Biebl]

Am Di., 11. Juni 2019 um 16:18 Uhr schrieb Reindl Harald
:
>
>
>
> Am 11.06.19 um 15:00 schrieb Ulrich Windl:
>  Reindl Harald  schrieb am 11.06.2019 um 14:30 in
> > Nachricht <917331d8-845f-54d5-908c-e6c7d124a...@thelounge.net>:
> >>
> >> Am 11.06.19 um 13:34 schrieb Ulrich Windl:
> >>> I have a forking service (with a PID file) that can reopen the logfile 
> >>> after
> >> receiving SIGHUP. In the past I had implemented "rc{service} rotate" to 
> >> send
> >> SIGHUP to the daemon as "postrotate" action. After converting (actually 
> >> being
> >> converted ;-)) to systemd I dropped the LSB script, and wonder which 
> >> command
> >> to use as "postrotate" action:
> >>>
> >>> Should I implement a oneshot service (using "systemctl start {service}")
> >> that does depend on the actual service and send a SIGHUP on start, or is
> >> there a more elegent solution?
> >>
> >> that's what reload is all about
> >>
> >> [harry@srv-rhsoft:/etc/systemd/system]$ cat named.service | grep Reload
> >> ExecReload=/usr/bin/kill -HUP $MAINPID
> >
> > The manual page says it's about "configuration reload". I was talking about 
> > logfile rotation (my service does not suport configuration reload (other 
> > than restart))
>
> frankly it's nothing new or uncommon that services close and re-open
> their logfiles by "reload" and that's really not systemd specific,
> sysvinit had reload too
>
> it's you turn what happens with "systemctl reload yourservice" becaus
> ethere is no default action for that unless "ExecReload" is specified

Of course you can do whatever you please in ExecReload, but as said I
think it's good practice if "reload" has a certain consistent meaning
across services so admins not familiar with a particular service know
what to expect from "systemctl reload".

See also
https://github.com/rsyslog/rsyslog/commit/fd26a42bdc04eaf497cafd9ef806a54f3de1a7e9#diff-c64e6ed7f40ecd1530e093a77c9465f6



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Anybody care to fix the list processor?

[Simon McVittie]

On Tue, 11 Jun 2019 at 15:44:07 +0200, Ulrich Windl wrote:
> Does anybody running the list care to fix the list-processor.

I don't think the members of this list
control its infrastructure, but I've opened
.

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

Re: [systemd-devel] Antw: Re: Q: Implementing logrotate's postrotate with systemd

[Reindl Harald]

Am 11.06.19 um 15:00 schrieb Ulrich Windl:
 Reindl Harald  schrieb am 11.06.2019 um 14:30 in
> Nachricht <917331d8-845f-54d5-908c-e6c7d124a...@thelounge.net>:
>>
>> Am 11.06.19 um 13:34 schrieb Ulrich Windl:
>>> I have a forking service (with a PID file) that can reopen the logfile 
>>> after 
>> receiving SIGHUP. In the past I had implemented "rc{service} rotate" to send 
>> SIGHUP to the daemon as "postrotate" action. After converting (actually 
>> being 
>> converted ;-)) to systemd I dropped the LSB script, and wonder which command 
>> to use as "postrotate" action:
>>>
>>> Should I implement a oneshot service (using "systemctl start {service}") 
>> that does depend on the actual service and send a SIGHUP on start, or is 
>> there a more elegent solution?
>>
>> that's what reload is all about
>>
>> [harry@srv-rhsoft:/etc/systemd/system]$ cat named.service | grep Reload
>> ExecReload=/usr/bin/kill -HUP $MAINPID
> 
> The manual page says it's about "configuration reload". I was talking about 
> logfile rotation (my service does not suport configuration reload (other than 
> restart))

frankly it's nothing new or uncommon that services close and re-open
their logfiles by "reload" and that's really not systemd specific,
sysvinit had reload too

it's you turn what happens with "systemctl reload yourservice" becaus
ethere is no default action for that unless "ExecReload" is specified
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Anybody care to fix the list processor?

[Ulrich Windl]

Hi!

Does anybody running the list care to fix the list-processor. The welcome 
message says:

You can also make such adjustments via email by sending a message to:

  systemd-devel-requ...@lists.freedesktop.org 

What you get is:
   The mail system

: host
gabe.freedesktop.org[2610:10:20:722:a800:ff:fe36:1795] said: 550 5.1.1
: Recipient address rejected:
User unknown in local recipient table (in reply to RCPT TO command)


Regards,
Ulrich


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

Re: [systemd-devel] Antw: Re: Q: Implementing logrotate's postrotate with systemd

[Michael Biebl]

Am Di., 11. Juni 2019 um 15:00 Uhr schrieb Ulrich Windl
:
>
> >>> Reindl Harald  schrieb am 11.06.2019 um 14:30 in
> Nachricht <917331d8-845f-54d5-908c-e6c7d124a...@thelounge.net>:
>
> >
> > Am 11.06.19 um 13:34 schrieb Ulrich Windl:
> >> I have a forking service (with a PID file) that can reopen the logfile 
> >> after
> > receiving SIGHUP. In the past I had implemented "rc{service} rotate" to send
> > SIGHUP to the daemon as "postrotate" action. After converting (actually 
> > being
> > converted ;-)) to systemd I dropped the LSB script, and wonder which command
> > to use as "postrotate" action:
> >>
> >> Should I implement a oneshot service (using "systemctl start {service}")
> > that does depend on the actual service and send a SIGHUP on start, or is
> > there a more elegent solution?
> >
> > that's what reload is all about
> >
> > [harry@srv-rhsoft:/etc/systemd/system]$ cat named.service | grep Reload
> > ExecReload=/usr/bin/kill -HUP $MAINPID
>
> The manual page says it's about "configuration reload". I was talking about 
> logfile rotation (my service does not suport configuration reload (other than 
> restart)).

Right, I wouldn't use ExecReload= for this use case myself.
If I run "systemctl reload $service", I expect that the service
reloads its configuration and I think it's good practice to be
consistent in that matter and not overload ExecReload= with "rotate
log files".


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Q: Implementing logrotate's postrotate with systemd

[Ulrich Windl]

>>> Reindl Harald  schrieb am 11.06.2019 um 14:30 in
Nachricht <917331d8-845f-54d5-908c-e6c7d124a...@thelounge.net>:

> 
> Am 11.06.19 um 13:34 schrieb Ulrich Windl:
>> I have a forking service (with a PID file) that can reopen the logfile after 
> receiving SIGHUP. In the past I had implemented "rc{service} rotate" to send 
> SIGHUP to the daemon as "postrotate" action. After converting (actually being 
> converted ;-)) to systemd I dropped the LSB script, and wonder which command 
> to use as "postrotate" action:
>> 
>> Should I implement a oneshot service (using "systemctl start {service}") 
> that does depend on the actual service and send a SIGHUP on start, or is 
> there a more elegent solution?
> 
> that's what reload is all about
> 
> [harry@srv-rhsoft:/etc/systemd/system]$ cat named.service | grep Reload
> ExecReload=/usr/bin/kill -HUP $MAINPID

The manual page says it's about "configuration reload". I was talking about 
logfile rotation (my service does not suport configuration reload (other than 
restart)).

> 
> [harry@srv-rhsoft:/etc/systemd/system]$ cat rsyslog.service | grep Reload
> ExecReload=/usr/bin/kill -HUP $MAINPID
> ___
> 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] keyrings and dbus

[Josef Moellers]

On 11.06.19 14:32, Josef Moellers wrote:
> On 11.06.19 13:27, Mantas Mikulėnas  wrote:
>> On Tue, Jun 11, 2019 at 1:58 PM Josef Moellers  
>> The point is that in the gnome-terminal case, pam_keyinit.so is not
>> involved.
>>
>>
>> It is. The systemd --user instance (from which dbus-daemon and
>> gnome-terminal-server descend) has its own PAM stack and can call
>> pam_keyinit.so if needed.
> 
> Strange thing is, that it already does!
> 
> /etc/pam.d/systemd-user:
> session  optional   pam_keyinit.so force revoke
> 
> So, even if a keyring exists, a new one user keyring would be created

That should have been "a new session keyring"
> ("force"), but apparently none exists.

Josef, confused but trying to continue
-- 
SUSE Linux GmbH
Maxfeldstrasse 5
90409 Nuernberg
Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] keyrings and dbus

[Josef Moellers]

On 11.06.19 13:27, Mantas Mikulėnas  wrote:
> On Tue, Jun 11, 2019 at 1:58 PM Josef Moellers  The point is that in the gnome-terminal case, pam_keyinit.so is not
> involved.
> 
> 
> It is. The systemd --user instance (from which dbus-daemon and
> gnome-terminal-server descend) has its own PAM stack and can call
> pam_keyinit.so if needed.

Strange thing is, that it already does!

/etc/pam.d/systemd-user:
session  optional   pam_keyinit.so force revoke

So, even if a keyring exists, a new one user keyring would be created
("force"), but apparently none exists.

Josef
-- 
SUSE Linux GmbH
Maxfeldstrasse 5
90409 Nuernberg
Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Q: Implementing logrotate's postrotate with systemd

[Reindl Harald]

Am 11.06.19 um 13:34 schrieb Ulrich Windl:
> I have a forking service (with a PID file) that can reopen the logfile after 
> receiving SIGHUP. In the past I had implemented "rc{service} rotate" to send 
> SIGHUP to the daemon as "postrotate" action. After converting (actually being 
> converted ;-)) to systemd I dropped the LSB script, and wonder which command 
> to use as "postrotate" action:
> 
> Should I implement a oneshot service (using "systemctl start {service}") that 
> does depend on the actual service and send a SIGHUP on start, or is there a 
> more elegent solution?

that's what reload is all about

[harry@srv-rhsoft:/etc/systemd/system]$ cat named.service | grep Reload
ExecReload=/usr/bin/kill -HUP $MAINPID

[harry@srv-rhsoft:/etc/systemd/system]$ cat rsyslog.service | grep Reload
ExecReload=/usr/bin/kill -HUP $MAINPID
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Q: Implementing logrotate's postrotate with systemd

[Ulrich Windl]

>>> Michael Biebl  schrieb am 11.06.2019 um 14:13 in Nachricht
:
> A separate oneshot service sounds like overkill. I would probably use
> something like
> `systemctl kill -s HUP ${service}.service`
> If your sevices spawns multiple processes and you only want to send
> SIGHUP to the main process, you should add a `--kill-who=main`

Thanks! I wasn't aware of systemctl's "kill".

Regards,
Ulrich

> 
> All documented nicely in
> https://www.freedesktop.org/software/systemd/man/systemctl.html 
> 
> Am Di., 11. Juni 2019 um 13:34 Uhr schrieb Ulrich Windl
> :
>>
>> Hi!
>>
>> I have a forking service (with a PID file) that can reopen the logfile after 
> receiving SIGHUP. In the past I had implemented "rc{service} rotate" to send 
> SIGHUP to the daemon as "postrotate" action. After converting (actually being 
> converted ;-)) to systemd I dropped the LSB script, and wonder which command 
> to use as "postrotate" action:
>>
>> Should I implement a oneshot service (using "systemctl start {service}") 
> that does depend on the actual service and send a SIGHUP on start, or is 
> there a more elegent solution?
>>
>> Regards,
>> Ulrich
>>
>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org 
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 
> 
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> ___
> 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] Q: Implementing logrotate's postrotate with systemd

[Michael Biebl]

A separate oneshot service sounds like overkill. I would probably use
something like
`systemctl kill -s HUP ${service}.service`
If your sevices spawns multiple processes and you only want to send
SIGHUP to the main process, you should add a `--kill-who=main`

All documented nicely in
https://www.freedesktop.org/software/systemd/man/systemctl.html

Am Di., 11. Juni 2019 um 13:34 Uhr schrieb Ulrich Windl
:
>
> Hi!
>
> I have a forking service (with a PID file) that can reopen the logfile after 
> receiving SIGHUP. In the past I had implemented "rc{service} rotate" to send 
> SIGHUP to the daemon as "postrotate" action. After converting (actually being 
> converted ;-)) to systemd I dropped the LSB script, and wonder which command 
> to use as "postrotate" action:
>
> Should I implement a oneshot service (using "systemctl start {service}") that 
> does depend on the actual service and send a SIGHUP on start, or is there a 
> more elegent solution?
>
> Regards,
> Ulrich
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Q: Implementing logrotate's postrotate with systemd

[Ulrich Windl]

Hi!

I have a forking service (with a PID file) that can reopen the logfile after 
receiving SIGHUP. In the past I had implemented "rc{service} rotate" to send 
SIGHUP to the daemon as "postrotate" action. After converting (actually being 
converted ;-)) to systemd I dropped the LSB script, and wonder which command to 
use as "postrotate" action:

Should I implement a oneshot service (using "systemctl start {service}") that 
does depend on the actual service and send a SIGHUP on start, or is there a 
more elegent solution?

Regards,
Ulrich



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

Re: [systemd-devel] keyrings and dbus

[Mantas Mikulėnas]

On Tue, Jun 11, 2019 at 1:58 PM Josef Moellers  wrote:

> On 11.06.19 12:45, Mantas Mikulėnas wrote:
> > On Tue, Jun 11, 2019 at 1:08 PM Josef Moellers  > > wrote:
> >
> > Hi,
> >
> > We have seen this problem: when you open a gnome-terminal, then the
> > shell in that terminal will not have the same keyring (created by
> > pam_keyinit.so) as the one eg in an xterm. This is due to the fact
> that
> > the xterm ist started by the standard fork/exec mechanism which
> passes
> > the keyring down to the children and the gnome-teminal (actually
> > gnome-terminal-server) is started by sending a dbus message to some
> > instance which the starts the terminal process.
> >
> > AAMOF the gnome-terminal does not even have a keyring, so if one asks
> > for it ("keyctl show @s"), it is created on the fly. This causes the
> > kernel to create a keyring as a "user session keyring" while the
> GNOME
> > session (and thus the xterm) has a "session keyring".
> >
> > Has anyone seen this and/or, most important question, does anyone
> have
> > an idea how to solve this?
> >
> > I know that, strictly speaking, this is not a systemd question, but
> > we're trying to probe many sources to see if anyone has a solution.
> >
> >
> > IIRC the usual advice by Lennart is to use the user-wide @u keyring
> > instead of session keyrings. (Programs searching in @s should
> > automatically find credentials added to @u, as pam_keyinit creates the
> > link by default.)
>
> Thanks Mantas,
>
> It's not the fact that the user keyring is missing, which it isn't, but
> it's the fact that a "user session keyring" rather than a "session
> keyring" is produced:
>

That is not what I was talking about...


>
> ssh:
> Keyring
>   69871887 --alswrv   1000   100  keyring: _ses
>  105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
> -> Session Keyring (_ses) linked to User Keyring (_uid.)
>
> gnome-terminal-server:
> Keyring
>  219457014 --alswrv   1000 65534  keyring: _uid_ses.1000
>  105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
> -> User Session Keyring (_uid_ses.) linked to User Keyring
> (_uid.)
>User Keyring is identical with User Keyring in ssh
>
> xterm:
> Keyring
>  633373159 --alswrv   1000   100  keyring: _ses
>  105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
> -> Session Keyring (_ses) linked to User Keyring (_uid.)
>User Keyring is identical with User Keyring in ssh
> -end of output-
>
> I'm not THAT familiar with the keyring mechanism, especially not with
> the actualy usage of them, but I don't know if one application or the
> other might later choke on the top level NOT being a "session keyring"
> but a "user session keyring".
>

Only if they do an explicit check for no good reason. AFAIK, other than the
name, both kinds of keyrings otherwise behave identically from a program's
perspective, and whenever the program asks for @s and there isn't one, the
kernel just automatically substitutes @us.

The only real issue is that programs won't be able to find *the actual
credentials* that were added to a different keyring.


>
> > You could probably alter pam_keyinit.so to allow joining an existing
> > session keyring (which is IIRC possible in the API). That way your
> > graphical sessions Ipam.d/gdm) would join the same @s created by systemd
> > --user instance (pam.d/systemd-user), which is the same one used by
> > dbus-daemon.
>
> The point is that in the gnome-terminal case, pam_keyinit.so is not
> involved.


It is. The systemd --user instance (from which dbus-daemon and
gnome-terminal-server descend) has its own PAM stack and can call
pam_keyinit.so if needed.

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

Re: [systemd-devel] keyrings and dbus

[Josef Moellers]

On 11.06.19 12:45, Mantas Mikulėnas wrote:
> On Tue, Jun 11, 2019 at 1:08 PM Josef Moellers  > wrote:
> 
> Hi,
> 
> We have seen this problem: when you open a gnome-terminal, then the
> shell in that terminal will not have the same keyring (created by
> pam_keyinit.so) as the one eg in an xterm. This is due to the fact that
> the xterm ist started by the standard fork/exec mechanism which passes
> the keyring down to the children and the gnome-teminal (actually
> gnome-terminal-server) is started by sending a dbus message to some
> instance which the starts the terminal process.
> 
> AAMOF the gnome-terminal does not even have a keyring, so if one asks
> for it ("keyctl show @s"), it is created on the fly. This causes the
> kernel to create a keyring as a "user session keyring" while the GNOME
> session (and thus the xterm) has a "session keyring".
> 
> Has anyone seen this and/or, most important question, does anyone have
> an idea how to solve this?
> 
> I know that, strictly speaking, this is not a systemd question, but
> we're trying to probe many sources to see if anyone has a solution.
> 
> 
> IIRC the usual advice by Lennart is to use the user-wide @u keyring
> instead of session keyrings. (Programs searching in @s should
> automatically find credentials added to @u, as pam_keyinit creates the
> link by default.)

Thanks Mantas,

It's not the fact that the user keyring is missing, which it isn't, but
it's the fact that a "user session keyring" rather than a "session
keyring" is produced:

ssh:
Keyring
  69871887 --alswrv   1000   100  keyring: _ses
 105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
-> Session Keyring (_ses) linked to User Keyring (_uid.)

gnome-terminal-server:
Keyring
 219457014 --alswrv   1000 65534  keyring: _uid_ses.1000
 105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
-> User Session Keyring (_uid_ses.) linked to User Keyring (_uid.)
   User Keyring is identical with User Keyring in ssh

xterm:
Keyring
 633373159 --alswrv   1000   100  keyring: _ses
 105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
-> Session Keyring (_ses) linked to User Keyring (_uid.)
   User Keyring is identical with User Keyring in ssh
-end of output-

I'm not THAT familiar with the keyring mechanism, especially not with
the actualy usage of them, but I don't know if one application or the
other might later choke on the top level NOT being a "session keyring"
but a "user session keyring".

> You could probably alter pam_keyinit.so to allow joining an existing
> session keyring (which is IIRC possible in the API). That way your
> graphical sessions Ipam.d/gdm) would join the same @s created by systemd
> --user instance (pam.d/systemd-user), which is the same one used by
> dbus-daemon.

The point is that in the gnome-terminal case, pam_keyinit.so is not
involved. My assumption (which the gnome developers still need to
verify/reject) is that the receiver of the "start gnome-terminal-server"
message either does not have a keyring to start with OR is careful
enough to dispose of whatever keyring it has and then starts the
terminal server without any keyring.

Thanks again,

Josef
-- 
SUSE Linux GmbH
Maxfeldstrasse 5
90409 Nuernberg
Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] keyrings and dbus

[Mantas Mikulėnas]

On Tue, Jun 11, 2019 at 1:08 PM Josef Moellers  wrote:

> Hi,
>
> We have seen this problem: when you open a gnome-terminal, then the
> shell in that terminal will not have the same keyring (created by
> pam_keyinit.so) as the one eg in an xterm. This is due to the fact that
> the xterm ist started by the standard fork/exec mechanism which passes
> the keyring down to the children and the gnome-teminal (actually
> gnome-terminal-server) is started by sending a dbus message to some
> instance which the starts the terminal process.
>
> AAMOF the gnome-terminal does not even have a keyring, so if one asks
> for it ("keyctl show @s"), it is created on the fly. This causes the
> kernel to create a keyring as a "user session keyring" while the GNOME
> session (and thus the xterm) has a "session keyring".
>
> Has anyone seen this and/or, most important question, does anyone have
> an idea how to solve this?
>
> I know that, strictly speaking, this is not a systemd question, but
> we're trying to probe many sources to see if anyone has a solution.
>
>
IIRC the usual advice by Lennart is to use the user-wide @u keyring instead
of session keyrings. (Programs searching in @s should automatically find
credentials added to @u, as pam_keyinit creates the link by default.)

A few years ago I have asked one affected kernel subsystem (cifs) to allow
using @u. They had no interest in doing so. I have since then decided to
just give up on being able to use cifs -o multiuser. (See also: GitHub
issue regarding AFS PAGs.)

You could probably alter pam_keyinit.so to allow joining an existing
session keyring (which is IIRC possible in the API). That way your
graphical sessions Ipam.d/gdm) would join the same @s created by systemd
--user instance (pam.d/systemd-user), which is the same one used by
dbus-daemon.

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

[systemd-devel] keyrings and dbus

[Josef Moellers]

Hi,

We have seen this problem: when you open a gnome-terminal, then the
shell in that terminal will not have the same keyring (created by
pam_keyinit.so) as the one eg in an xterm. This is due to the fact that
the xterm ist started by the standard fork/exec mechanism which passes
the keyring down to the children and the gnome-teminal (actually
gnome-terminal-server) is started by sending a dbus message to some
instance which the starts the terminal process.

AAMOF the gnome-terminal does not even have a keyring, so if one asks
for it ("keyctl show @s"), it is created on the fly. This causes the
kernel to create a keyring as a "user session keyring" while the GNOME
session (and thus the xterm) has a "session keyring".

Has anyone seen this and/or, most important question, does anyone have
an idea how to solve this?

I know that, strictly speaking, this is not a systemd question, but
we're trying to probe many sources to see if anyone has a solution.

Josef

-- 
SUSE Linux GmbH
Maxfeldstrasse 5
90409 Nuernberg
Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)


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

Re: [systemd-devel] systemd-networkd: keeping old routes when new dhcp lease was given

[William Kennington]

Probably related to this issue
https://github.com/systemd/systemd/pull/12350


On Tue, Jun 11, 2019 at 02:25 Kaisrlík, Jan  wrote:

> Hello here,
>
> I am running Yocto-thud with systemd 239 on my SoC and I've found
> interesting, when DHCP lease was prolonged, I observe the connection
> to the internet was completely stopped.
>
> Based on the logs in the system I strongly believe it is connected to
> moment when networkd renews a dhcp lease when it expires:
>
> # cat /var/log/daemon.log  | grep "networkd\["
> 2019-05-29T11:55:12.159213+00:00 x systemd-networkd[250]: Enumeration
> completed
> 2019-05-29T11:55:12.159253+00:00 x systemd-networkd[250]: lo: Link is not
> managed by us
> 2019-05-29T11:55:12.159294+00:00 x systemd-networkd[250]: veth0: netdev
> ready
> 2019-05-29T11:55:12.170082+00:00 x systemd-networkd[250]:
> request_name_destroy_callback n_ref=1
> 2019-05-29T11:55:14.053408+00:00 x systemd-networkd[250]: eth0: Gained
> carrier
> 2019-05-29T11:55:14.058588+00:00 x systemd-networkd[250]: veth0: Gained
> carrier
> 2019-05-29T11:55:15.057317+00:00 x systemd-networkd[250]: eth0: DHCPv4
> address 192.168.0.122/24 via 192.168.0.1
> 2019-05-29T11:55:15.088632+00:00 x systemd-networkd[250]: veth0: Gained
> IPv6LL
> 2019-05-29T11:55:15.088833+00:00 x systemd-networkd[250]: veth0: Configured
> 2019-05-29T11:55:15.632514+00:00 x systemd-networkd[250]: eth0: Gained
> IPv6LL
> 2019-05-29T11:55:15.632621+00:00 x systemd-networkd[250]: eth0: Configured
> 2019-05-29T11:55:23.787104+00:00 x systemd-networkd[250]: tun0: Gained
> carrier
> 2019-05-29T11:55:23.787425+00:00 x systemd-networkd[250]: tun0: Gained
> IPv6LL
> 2019-06-03T08:27:42.019202+00:00 x systemd-networkd[250]: tun0: Lost
> carrier
> 2019-06-03T08:28:14.017067+00:00 x systemd-networkd[250]: tun0: Gained
> carrier
> 2019-06-03T08:28:14.017287+00:00 x systemd-networkd[250]: tun0: Gained
> IPv6LL
> 2019-06-04T05:27:31.261841+00:00 x systemd-networkd[250]: eth0: DHCPv4
> address 192.168.0.125/24 via 192.168.0.1
> 2019-06-04T08:27:56.178984+00:00 x systemd-networkd[250]: tun0: Lost
> carrier
>
> From the log above you can observe the lease was prolonged
> successfully and new ip address was given and from this particular
> moment the board was not able to connect to the internet.
> During the debugging I found this : the routes in the system are wrong
> and route with old ip address still exists in the system.
>
> # ip route
> default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.122 metric 1024
> default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.125 metric 1024
> 10.1.2.252/30 dev veth0 proto kernel scope link src 10.255.254.253
> 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.125
> 192.168.0.1 dev eth0 proto dhcp scope link src 192.168.0.122 metric 1024
> 192.168.0.1 dev eth0 proto dhcp scope link src 192.168.0.125 metric 1024
>
> In addition I'm adding outputs from ip tool and networkctl.
>
> # ip addr show eth0
> 2: eth0:  mtu 1500 qdisc mq state UP
> group default qlen 1000
> link/ether e0:91:53:a3:9a:81 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.125/24 brd 192.168.0.255 scope global dynamic eth0
>valid_lft 55210sec preferred_lft 55210sec
> inet6 fe80::e291:53ff:fea3:9a81/64 scope link
>valid_lft forever preferred_lft forever
>
> # networkctl status eth0
> ● 2: eth0
>Link File: /lib/systemd/network/99-default.link
> Network File: /etc/systemd/network/eth-p2p.network
> Type: ether
>State: routable (configured)
> Path: platform-ff3f.ethernet
>   HW Address: e0:91:53:a3:9a:81 (XAVi Technologies Corp.)
>  Address: 192.168.0.125
>   fe80::e291:53ff:fea3:9a81
>  Gateway: 192.168.0.1 (Tenda Technology Co.,Ltd.Dongguan branch)
>   192.168.0.1 (Tenda Technology Co.,Ltd.Dongguan branch)
>  DNS: 192.168.0.1
>
> What is even more interesting is the following output which does not
> fully correlate with output from ip and networkctl.
>
> # cat /run/systemd/netif/links/2
> # This is private data. Do not parse.
> ADMIN_STATE=configured
> OPER_STATE=routable
> REQUIRED_FOR_ONLINE=yes
> NETWORK_FILE=/etc/systemd/network/eth-p2p.network
> DNS=192.168.0.1
> NTP=
> DOMAINS=
> ROUTE_DOMAINS=
> LLMNR=yes
> MDNS=no
> ADDRESSES=192.168.0.125/24 192.168.0.122/24
> ROUTES=192.168.0.1/32/0/1024/254/18446744073709551615
> 0.0.0.0/0/0/1024/254/18446744073709551615
> DHCP4_ADDRESS=192.168.0.125
> DHCP_LEASE=/run/systemd/netif/leases/2
>
> Unfortunately, pcaps and more verbose systemd logs are not currently
> available.
>
> Have you ever seen similar issue?
>
> Thank you in you advice.
>
> Best regards,
>
> --
> Jan Kaisrlik
> ___
> 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

[systemd-devel] systemd-networkd: keeping old routes when new dhcp lease was given

[Kaisrlík , Jan]

Hello here,

I am running Yocto-thud with systemd 239 on my SoC and I've found
interesting, when DHCP lease was prolonged, I observe the connection
to the internet was completely stopped.

Based on the logs in the system I strongly believe it is connected to
moment when networkd renews a dhcp lease when it expires:

# cat /var/log/daemon.log  | grep "networkd\["
2019-05-29T11:55:12.159213+00:00 x systemd-networkd[250]: Enumeration
completed
2019-05-29T11:55:12.159253+00:00 x systemd-networkd[250]: lo: Link is not
managed by us
2019-05-29T11:55:12.159294+00:00 x systemd-networkd[250]: veth0: netdev
ready
2019-05-29T11:55:12.170082+00:00 x systemd-networkd[250]:
request_name_destroy_callback n_ref=1
2019-05-29T11:55:14.053408+00:00 x systemd-networkd[250]: eth0: Gained
carrier
2019-05-29T11:55:14.058588+00:00 x systemd-networkd[250]: veth0: Gained
carrier
2019-05-29T11:55:15.057317+00:00 x systemd-networkd[250]: eth0: DHCPv4
address 192.168.0.122/24 via 192.168.0.1
2019-05-29T11:55:15.088632+00:00 x systemd-networkd[250]: veth0: Gained
IPv6LL
2019-05-29T11:55:15.088833+00:00 x systemd-networkd[250]: veth0: Configured
2019-05-29T11:55:15.632514+00:00 x systemd-networkd[250]: eth0: Gained
IPv6LL
2019-05-29T11:55:15.632621+00:00 x systemd-networkd[250]: eth0: Configured
2019-05-29T11:55:23.787104+00:00 x systemd-networkd[250]: tun0: Gained
carrier
2019-05-29T11:55:23.787425+00:00 x systemd-networkd[250]: tun0: Gained
IPv6LL
2019-06-03T08:27:42.019202+00:00 x systemd-networkd[250]: tun0: Lost carrier
2019-06-03T08:28:14.017067+00:00 x systemd-networkd[250]: tun0: Gained
carrier
2019-06-03T08:28:14.017287+00:00 x systemd-networkd[250]: tun0: Gained
IPv6LL
2019-06-04T05:27:31.261841+00:00 x systemd-networkd[250]: eth0: DHCPv4
address 192.168.0.125/24 via 192.168.0.1
2019-06-04T08:27:56.178984+00:00 x systemd-networkd[250]: tun0: Lost carrier

>From the log above you can observe the lease was prolonged
successfully and new ip address was given and from this particular
moment the board was not able to connect to the internet.
During the debugging I found this : the routes in the system are wrong
and route with old ip address still exists in the system.

# ip route
default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.122 metric 1024
default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.125 metric 1024
10.1.2.252/30 dev veth0 proto kernel scope link src 10.255.254.253
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.125
192.168.0.1 dev eth0 proto dhcp scope link src 192.168.0.122 metric 1024
192.168.0.1 dev eth0 proto dhcp scope link src 192.168.0.125 metric 1024

In addition I'm adding outputs from ip tool and networkctl.

# ip addr show eth0
2: eth0:  mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether e0:91:53:a3:9a:81 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.125/24 brd 192.168.0.255 scope global dynamic eth0
   valid_lft 55210sec preferred_lft 55210sec
inet6 fe80::e291:53ff:fea3:9a81/64 scope link
   valid_lft forever preferred_lft forever

# networkctl status eth0
● 2: eth0
   Link File: /lib/systemd/network/99-default.link
Network File: /etc/systemd/network/eth-p2p.network
Type: ether
   State: routable (configured)
Path: platform-ff3f.ethernet
  HW Address: e0:91:53:a3:9a:81 (XAVi Technologies Corp.)
 Address: 192.168.0.125
  fe80::e291:53ff:fea3:9a81
 Gateway: 192.168.0.1 (Tenda Technology Co.,Ltd.Dongguan branch)
  192.168.0.1 (Tenda Technology Co.,Ltd.Dongguan branch)
 DNS: 192.168.0.1

What is even more interesting is the following output which does not
fully correlate with output from ip and networkctl.

# cat /run/systemd/netif/links/2
# This is private data. Do not parse.
ADMIN_STATE=configured
OPER_STATE=routable
REQUIRED_FOR_ONLINE=yes
NETWORK_FILE=/etc/systemd/network/eth-p2p.network
DNS=192.168.0.1
NTP=
DOMAINS=
ROUTE_DOMAINS=
LLMNR=yes
MDNS=no
ADDRESSES=192.168.0.125/24 192.168.0.122/24
ROUTES=192.168.0.1/32/0/1024/254/18446744073709551615
0.0.0.0/0/0/1024/254/18446744073709551615
DHCP4_ADDRESS=192.168.0.125
DHCP_LEASE=/run/systemd/netif/leases/2

Unfortunately, pcaps and more verbose systemd logs are not currently
available.

Have you ever seen similar issue?

Thank you in you advice.

Best regards,
-- 
Jan Kaisrlik
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel