On Mon, Jan 22, 2018 at 7:49 AM, Pekka Paalanen wrote:
> On Fri, 29 Dec 2017 15:09:28 -0600
> Matt Hoosier wrote:
>
>> Hi Lennart,
>>
>> On Mon, Dec 4, 2017 at 9:11 AM, Pekka Paalanen wrote:
>> > On Fri, 1 Dec 2017 18:25:35 +0100
>> > Lennart P
On Dec 29, 2017 15:32, "Mantas Mikulėnas" wrote:
On Fri, Dec 29, 2017 at 11:09 PM, Matt Hoosier
wrote:
>
> The approach that you and Pekka most recently put on record here:
>
> * User=foo
> * PAMName=weston
>
> with a /etc/pam.d/weston that just does minimal stuf
Hi Lennart,
On Mon, Dec 4, 2017 at 9:11 AM, Pekka Paalanen wrote:
> On Fri, 1 Dec 2017 18:25:35 +0100
> Lennart Poettering wrote:
>
>> On Fr, 01.12.17 13:42, Pekka Paalanen (ppaala...@gmail.com) wrote:
>>
>> > > > > This is racy, as the session ID is not really reliably predictable,
>> > > > > a
I'm trying to figure out the root cause of some failures of regular old
libdbus1-using programs when /var/run/dbus/system_bus_socket happens to be
provided by systemd-bus-proxyd.
The programs in question attempt to invoke org.freedesktop.DBus.AddMatch()
with the rule-parameter having the value:
ual/aliased service name.
Am I wrong in that assessment in the preceding paragraph?
On Mon, Apr 20, 2015 at 12:49 PM, Lennart Poettering wrote:
> On Mon, 20.04.15 12:12, Matt Hoosier (matt.hoos...@gmail.com) wrote:
>
> > > > inexperienced poking around the inter
On Mon, Apr 20, 2015 at 9:11 AM, Lennart Poettering
wrote:
> On Fri, 17.04.15 14:06, Matt Hoosier (matt.hoos...@gmail.com) wrote:
>
> > The bootcharting that I do seems to show that about 1.2 - 1.5 sec are
> spent
> > internal to systemd before any external proc
On Fri, Apr 17, 2015 at 3:52 PM, Cristian Rodríguez <
crrodrig...@opensuse.org> wrote:
> On Fri, Apr 17, 2015 at 4:06 PM, Matt Hoosier
> wrote:
> > On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering
> > wrote:
> >>
> >> On Fri, 17.04.15 09:00, M
On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering wrote:
> On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoos...@gmail.com) wrote:
>
> > Hi,
> >
> > I'm writing to see whether there's a "best" way to allow systemd to
> inherit
> > ownersh
Hi,
I'm writing to see whether there's a "best" way to allow systemd to inherit
ownership of a process forked from a hand-crafted /sbin/init process before
that hand-crafted process turns over the keys to systemd by doing
exec("/lib/systemd/systemd") over the top of itself and allowing it to take
