On Sat, Jul 19, 2014 at 10:37 AM, Thomas H.P. Andersen wrote:
> From: Thomas Hindoe Paaboel Andersen
>
> ---
> src/resolve/resolved-dns-scope.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/resolve/resolved-dns-scope.c
> b/src/resolve/resolved-dns-scope.c
> in
Hi
On Mon, Aug 11, 2014 at 4:08 PM, Tom Gundersen wrote:
> On Sat, Aug 9, 2014 at 7:59 PM, Anatol Pomozov
> wrote:
>> I have a router where I experiment with OpenWRT. I sysupdate (i.e.
>> reinstall) openwrt regularly, once or twice a week. I also have an
>> Arch home server with the latest syst
On Wed, Aug 6, 2014 at 6:17 PM, Dan Williams wrote:
> The caller may have an existing DUID that it wants to use, and may
> want to use some other DUID generation scheme than systemd's
> default DUID-EN.
I have no objections a priori to this patch. But what is the use case?
Is there some DUID sche
On Sat, Aug 9, 2014 at 7:59 PM, Anatol Pomozov wrote:
> I have a router where I experiment with OpenWRT. I sysupdate (i.e.
> reinstall) openwrt regularly, once or twice a week. I also have an
> Arch home server with the latest systemd. The machine connected via
> ethernet cable.
>
> Every time I r
> Van: Koen Kooi [[email protected]]
> Verzonden: maandag 11 augustus 2014 13:19
>
> Op 11 aug. 2014, om 12:47 heeft Lennart Poettering
> het volgende geschreven:
>
>> On Sat, 09.08.14 06:44, Paassen, Hiram van
>> ([email protected]) wrote:
>>
>>> Am I correct in thinking
Separating the unit to sync time from the ones featuring OnCalendar by
time-sync.target (or any arbitrary target used as "separating wall")
worked exactly as expected on ARM and is indeed a workaround for the
problem.
Couldn't reproduce the need to set DefaultDependencies=No in the units
featur
On Mon, 11.08.14 19:48, tomw ([email protected]) wrote:
>
> > This looks weird. You first become user "xyzuser", then you run sudo
> > again, to become "xyzuser"? What's that supposed to do? Why involve
> > "sudo" here at all? You could also use PAMName= directly...?
>
> Thanks for your helpful co
On 08/11/14 18:21, David Herrmann wrote:
> sd-event does not allow multiple handlers for a single signal. However,
> logind sets up signal handlers for each session with VT_PROCESS set (that
> is, it has an active controller). Therefore, registering multiple such
> controllers will fail.
>
> Lets
> This looks weird. You first become user "xyzuser", then you run sudo
> again, to become "xyzuser"? What's that supposed to do? Why involve
> "sudo" here at all? You could also use PAMName= directly...?
Thanks for your helpful comments. This setup is intended to boot
directly into an application
Hi,
I am seeing an oddity in the CGroup output of systemctl status ran on
some units. On the other hand, systemd-cgls shows correct information.
Here is an example:
--
$ systemctl status [email protected]
[email protected] - DHCP connection on bond0
Loaded: loaded (/etc/
On Mon, Aug 11, 2014 at 12:57 PM, Lennart Poettering
wrote:
> On Mon, 11.08.14 18:39, Luis R. Rodriguez ([email protected]) wrote:
>
>> > This looks really wrong. We shouldn't permit worker processes to be
>> > blocked indefinitely without any timeout applied. Designing a worker
>> > process system
On Mon, 11.08.14 18:39, Luis R. Rodriguez ([email protected]) wrote:
> > This looks really wrong. We shouldn't permit worker processes to be
> > blocked indefinitely without any timeout applied. Designing a worker
> > process system like that is simply wrong. It's one thing to allow
> > changing the
On Thu, 07.08.14 15:21, Dimitri John Ledkov ([email protected])
wrote:
> From: Dimitri John Ledkov
>
> tmpfiles.d files do not depend on /usr present, and in
> --enable-split-usr configuration there may be system units
> (e.g. shipped in /lib) that rely on tmpfiles.d to be configured
Hi
On Mon, Aug 11, 2014 at 6:54 PM, Lennart Poettering
wrote:
> On Mon, 11.08.14 18:46, Lennart Poettering ([email protected]) wrote:
>
>> With this code you block, but do not ignore SGRTMIN+1. Now, rtsigs
>> actually are implemented in a queue, multiple instances of the same
>> signal might
On Mon, 11.08.14 18:46, Lennart Poettering ([email protected]) wrote:
> With this code you block, but do not ignore SGRTMIN+1. Now, rtsigs
> actually are implemented in a queue, multiple instances of the same
> signal might be queued up. If you simply block dispatching, then the
> queue will
On Mon, 11.08.14 18:21, David Herrmann ([email protected]) wrote:
> +/*
> + * SIGRTMIN is used as global VT-release signal, SIGRTMIN + 1 is used
> + * as VT-acquire signal. We ignore any acquire-events (yes, we still
> + * have to provide a valid signal-number f
Hi
On Mon, Aug 11, 2014 at 5:37 PM, Olivier Brunel wrote:
> On 08/11/14 17:12, David Herrmann wrote:
>> Wait, what? Can you please elaborate. Currently, only one process can
>
> Sorry, I meant e.g. having one rootless X on tt1 and starting another
> one on tty2. Currently this fails (see other pa
Hi
On Mon, Aug 11, 2014 at 6:13 PM, Lennart Poettering
wrote:
> On Mon, 11.08.14 17:17, David Herrmann ([email protected]) wrote:
>
>>
>> Hi
>>
>> On Fri, Aug 8, 2014 at 8:45 PM, Olivier Brunel wrote:
>> > If controllers can expect logind to have "prepared" the VT (e.g. set it to
>> > graphi
On Mon, Aug 11, 2014 at 03:50:47PM +0200, Lennart Poettering wrote:
> On Fri, 08.08.14 19:16, Luis R. Rodriguez ([email protected]) wrote:
>
> This looks really wrong. We shouldn't permit worker processes to be
> blocked indefinitely without any timeout applied. Designing a worker
> process
sd-event does not allow multiple handlers for a single signal. However,
logind sets up signal handlers for each session with VT_PROCESS set (that
is, it has an active controller). Therefore, registering multiple such
controllers will fail.
Lets make the VT-handler global, as it's mostly trivial, a
On Mon, 11.08.14 17:17, David Herrmann ([email protected]) wrote:
>
> Hi
>
> On Fri, Aug 8, 2014 at 8:45 PM, Olivier Brunel wrote:
> > If controllers can expect logind to have "prepared" the VT (e.g. set it to
> > graphics mode, etc) then TakeControl() should fail if said preparation
> > fa
On 08/11/14 17:12, David Herrmann wrote:
> Hi
>
> On Mon, Aug 11, 2014 at 5:05 PM, Olivier Brunel wrote:
>> On 08/11/14 16:54, Lennart Poettering wrote:
>>> On Mon, 11.08.14 16:39, Olivier Brunel ([email protected]) wrote:
>>>
On 08/11/14 16:25, Lennart Poettering wrote:
> On Fri, 08.
Hi
On Mon, Aug 11, 2014 at 4:52 PM, Lennart Poettering
wrote:
> On Mon, 11.08.14 16:46, Olivier Brunel ([email protected]) wrote:
>
>>
>> On 08/11/14 16:34, Lennart Poettering wrote:
>> > On Fri, 08.08.14 20:45, Olivier Brunel ([email protected]) wrote:
>> >
>> >> While a session can only ever have o
Hi
On Fri, Aug 8, 2014 at 8:45 PM, Olivier Brunel wrote:
> If controllers can expect logind to have "prepared" the VT (e.g. set it to
> graphics mode, etc) then TakeControl() should fail if said preparation
> failed (and session_restore_vt() was called).
> ---
> src/login/logind-session.c | 15 +
Hi
On Mon, Aug 11, 2014 at 5:05 PM, Olivier Brunel wrote:
> On 08/11/14 16:54, Lennart Poettering wrote:
>> On Mon, 11.08.14 16:39, Olivier Brunel ([email protected]) wrote:
>>
>>>
>>> On 08/11/14 16:25, Lennart Poettering wrote:
On Fri, 08.08.14 20:45, Olivier Brunel ([email protected]) wrote:
On 08/11/14 16:54, Lennart Poettering wrote:
> On Mon, 11.08.14 16:39, Olivier Brunel ([email protected]) wrote:
>
>>
>> On 08/11/14 16:25, Lennart Poettering wrote:
>>> On Fri, 08.08.14 20:45, Olivier Brunel ([email protected]) wrote:
>>>
In session_prepare_vt() we set owner of /dev/ttyX to the
On Mon, 11.08.14 16:39, Olivier Brunel ([email protected]) wrote:
>
> On 08/11/14 16:25, Lennart Poettering wrote:
> > On Fri, 08.08.14 20:45, Olivier Brunel ([email protected]) wrote:
> >
> >> In session_prepare_vt() we set owner of /dev/ttyX to the user, as that is
> >> needed for things to work.
On Mon, 11.08.14 16:46, Olivier Brunel ([email protected]) wrote:
>
> On 08/11/14 16:34, Lennart Poettering wrote:
> > On Fri, 08.08.14 20:45, Olivier Brunel ([email protected]) wrote:
> >
> >> While a session can only ever have one controller, there can be more than
> >> one session with a controll
On 08/11/14 16:34, Lennart Poettering wrote:
> On Fri, 08.08.14 20:45, Olivier Brunel ([email protected]) wrote:
>
>> While a session can only ever have one controller, there can be more than
>> one session with a controller at a time. However, because of the handling
>> of SIGUSR1 for handling VT s
On 08/11/14 16:25, Lennart Poettering wrote:
> On Fri, 08.08.14 20:45, Olivier Brunel ([email protected]) wrote:
>
>> In session_prepare_vt() we set owner of /dev/ttyX to the user, as that is
>> needed for things to work. However, we shouldn't "reset" it to root on
>> session_restore_vt() since it c
On Fri, 08.08.14 20:45, Olivier Brunel ([email protected]) wrote:
> While a session can only ever have one controller, there can be more than
> one session with a controller at a time. However, because of the handling
> of SIGUSR1 for handling VT switch, trying to set a controller on a session
> whi
On Fri, 08.08.14 20:45, Olivier Brunel ([email protected]) wrote:
> In session_prepare_vt() we set owner of /dev/ttyX to the user, as that is
> needed for things to work. However, we shouldn't "reset" it to root on
> session_restore_vt() since it could have in fact already been set to
> the user.
I
On Fri, 08.08.14 10:44, tomw ([email protected]) wrote:
> Hi,
>
> migrating from sysV to systemd I ran into some issues with random
> behavior of session bus availability. The setup is as follows:
>
> systemd starts a service which starts an x-session like this:
>
> [Unit]
> Description=Master P
On Mon, 2014-08-11 at 15:57 +0200, Lennart Poettering wrote:
> On Fri, 08.08.14 17:00, [email protected] ([email protected]) wrote:
>
> > From: Harald Hoyer
> >
> > According to Brent Baude , who provided the patch,
> > IBM doesn't want to support the PPC 32 bit LE architecture at all.
>
> What
On Mon, 11.08.14 15:57, Lennart Poettering ([email protected]) wrote:
> On Fri, 08.08.14 17:00, [email protected] ([email protected]) wrote:
>
> > From: Harald Hoyer
> >
> > According to Brent Baude , who provided the patch,
> > IBM doesn't want to support the PPC 32 bit LE architecture at
On Fri, 08.08.14 19:16, Luis R. Rodriguez ([email protected]) wrote:
This looks really wrong. We shouldn't permit worker processes to be
blocked indefinitely without any timeout applied. Designing a worker
process system like that is simply wrong. It's one thing to allow
changing the specifi
On Fri, 08.08.14 17:00, [email protected] ([email protected]) wrote:
> From: Harald Hoyer
>
> According to Brent Baude , who provided the patch,
> IBM doesn't want to support the PPC 32 bit LE architecture at all.
What is "support" supposed to mean? Does that mean that the silicon for
PPC32LE h
On Mon, 11.08.14 13:41, Markus Weißmann ([email protected]) wrote:
Hi!
> I've got an embedded system which can run in two configurations;
> configuration 1 will run daemon A, B and C
> configuration 2 will run daemon A and D
> The configuration is chosen at boot-time with a hardware swit
Hello systemd,
I've got an embedded system which can run in two configurations;
configuration 1 will run daemon A, B and C
configuration 2 will run daemon A and D
The configuration is chosen at boot-time with a hardware switch. The
position of this switch is accessible with a userland tool (via
Op 11 aug. 2014, om 12:47 heeft Lennart Poettering het
volgende geschreven:
> On Sat, 09.08.14 06:44, Paassen, Hiram van ([email protected])
> wrote:
>
>> Am I correct in thinking this only works on systemd enabled host
>> systems or if you cross-compile for the same architectu
On Thu, 07.08.14 15:09, Peter Mattern ([email protected]) wrote:
>
> First, thank you very much for your quick responses.
>
> I had missed the description in man systemd.unit ("If any of these
> options is assigned the empty string, ..." at the end of the
> paragraph about Condition*, right?) an
On Sat, 09.08.14 06:44, Paassen, Hiram van ([email protected])
wrote:
> Am I correct in thinking this only works on systemd enabled host
> systems or if you cross-compile for the same architecture? So you can
> use the just compiled version of systemctl?
Well, what do you expect?
On Fri, 08.08.14 18:00, Mateusz Jończyk ([email protected]) wrote:
> Both issues could be solved by patching nss_myhostname:
> - some configuration file which specifies which IP addresses to expose for
> the
> local hostname,
> - reverse resolution may also be configurable, for example we could
On Fri, 08.08.14 12:07, Mateusz Jończyk ([email protected]) wrote:
Heya,
> Hello,
> The man page for nss-myhostname:
> http://www.freedesktop.org/software/systemd/man/nss-myhostname.html
> suggests that myhostname should be used as a last entry in
> /etc/nsswitch.conf:
> "It is recommended to put
44 matches
Mail list logo
