On Mon, Jul 2, 2012 at 4:20 PM, Paul Menzel
wrote:
>> "Before=, After=
>> Configures ordering dependencies between units. If a unit foo.service
>> contains a setting Before=bar.service and both units are being
>> started, bar.service's start-up is delayed until foo.service is
>> started up.
>
> So
On Mon, Jul 2, 2012 at 3:44 PM, Paul Menzel
wrote:
>> > daemon actually finds a NTP server.
>>
>> Also, is this necessary? Can't chronyd just fail to sync NTP until it
>> works? There's value to an NTP daemon running even if it lacks
>> upstream sync sources for a while.
>
> Which? But it might be
2012/7/3 Lennart Poettering :
> On Sat, 30.06.12 13:47, Paul Menzel (paulepan...@users.sourceforge.net) wrote:
>
>>
>> Well, no. Debian still ships an init.d script which reads
>> `/etc/default/pulseaudio` and there system mode is disabled by default.
>> So I masked this one too.
>>
>> $ sudo
On Tue, Jul 03, 2012 at 02:24:57AM +0200, Lennart Poettering wrote:
> On Sun, 01.07.12 19:37, Dave Reisner (dreis...@archlinux.org) wrote:
>
> > A broken .include link in a unit file will cause 'systemctl
> > list-unit-files' to simply return 'No such file or directory'. Ignore
> > this silly erro
Hello,
I am experimenting with systemd on redhat 6.
I have built 2 custom kernels:
1. one is essentially a desktop kernel (essentially a fedora kernel)
2. one is a stripped down kernel with many things removed.
on a normal redhat 6 box both of these kernels work without issue.
on my test s
On Sat, 30.06.12 13:47, Paul Menzel (paulepan...@users.sourceforge.net) wrote:
> > >509ms vdr.service
> > >487ms sysfsutils.service
> >
> > What is this? This stuff sounds like something that can just go away...
>
> I was surprised too. It looks like this was installed by
> `grml-deboots
On Sun, 01.07.12 19:37, Dave Reisner (dreis...@archlinux.org) wrote:
> A broken .include link in a unit file will cause 'systemctl
> list-unit-files' to simply return 'No such file or directory'. Ignore
> this silly error, since we know that the file really does exist.
Hmm, I figure we should at
On Tue, Jul 3, 2012 at 1:20 AM, Paul Menzel
wrote:
> Am Dienstag, den 03.07.2012, 00:55 +0200 schrieb Kay Sievers:
>> On Tue, Jul 3, 2012 at 12:44 AM, Paul Menzel wrote:
>> >> I'm also generally skeptical of After= without a corresponding
>> >> Requires= entry because it only affects the ordering
On Mon, Jul 2, 2012 at 2:05 PM, David Strauss wrote:
> On Mon, Jul 2, 2012 at 2:01 PM, Kok, Auke-jan H
> wrote:
>> that was without /var/log/journal existing, so, all in-memory.
>
> Wow, that's an awful lot of CPU time in that case. Has anyone looked
> into this? I'd like someone to start a dive
Am Dienstag, den 03.07.2012, 00:55 +0200 schrieb Kay Sievers:
> On Tue, Jul 3, 2012 at 12:44 AM, Paul Menzel wrote:
> >> I'm also generally skeptical of After= without a corresponding
> >> Requires= entry because it only affects the ordering if the other unit
> >> is already present in the working
On Tue, Jul 3, 2012 at 12:44 AM, Paul Menzel
wrote:
>> I'm also generally skeptical of After= without a corresponding
>> Requires= entry because it only affects the ordering if the other unit
>> is already present in the working set of services then being started.
>
> I did not get that. The manua
Am Montag, den 02.07.2012, 13:04 -0700 schrieb David Strauss:
> On Fri, Jun 29, 2012 at 4:00 PM, Paul Menzel wrote:
> > Additionally `After=nss-lockup.target` should be set, so that the NTP
Ah, nice typo I got here: s/lockup/lookup/.
> > daemon actually finds a NTP server.
>
> Also, is this nece
On Sat, 30.06.12 16:33, Colin Guthrie (co...@mageia.org) wrote:
> This naming convention is more inline with other systemd daemon
> unit names (systemd-logind.service, systemd-localed.service etc)
>
> The companion .socket units have also been renamed, however the
> -trigger and -settle units kee
On Mon, Jul 2, 2012 at 2:01 PM, Kok, Auke-jan H
wrote:
> that was without /var/log/journal existing, so, all in-memory.
Wow, that's an awful lot of CPU time in that case. Has anyone looked
into this? I'd like someone to start a dive to uncover such issues in
detail well before hosting a sprint. I
On Mon, Jul 2, 2012 at 12:55 PM, David Strauss wrote:
> On Fri, Jun 29, 2012 at 2:23 PM, Kok, Auke-jan H
> wrote:
>> I'm somewhat concerned about the large amount of CPU utilization
>> that I've seen with the journal, so, I'd consider putting some time
>> into optimizing the journal internal code
On Fri, Jun 29, 2012 at 4:00 PM, Paul Menzel
wrote:
> Additionally `After=nss-lockup.target` should be set, so that the NTP
> daemon actually finds a NTP server.
Also, is this necessary? Can't chronyd just fail to sync NTP until it
works? There's value to an NTP daemon running even if it lacks
up
On Fri, Jun 29, 2012 at 4:00 PM, Paul Menzel
wrote:
> So does the last service file look reasonable and should be used for
> upstream inclusion?
The After=syslog.target part is probably unnecessary given how systemd
handles buffering the syslog socket.
--
David Strauss
| da...@davidstrauss.n
On Fri, Jun 29, 2012 at 2:23 PM, Kok, Auke-jan H
wrote:
> I'm somewhat concerned about the large amount of CPU utilization
> that I've seen with the journal, so, I'd consider putting some time
> into optimizing the journal internal code.
>
> The concern was that on one of our systems we had a larg
On Mon, 02.07.12 09:15, Colin Guthrie (co...@mageia.org) wrote:
> This seems to have been a problem since mageia support was merged,
> as upstream had changed how this bit worked without us realising.
> ---
> configure.ac | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/c
'Twas brillig, and Lennart Poettering at 02/07/12 09:48 did gyre and gimble:
> On Mon, 02.07.12 09:15, Colin Guthrie (co...@mageia.org) wrote:
>
>> On some really old hardware, the default timeout of 120 (which may even
>> be reduced further on the command line) is insufficient.
>>
>> While such c
On Mon, 02.07.12 09:15, Colin Guthrie (co...@mageia.org) wrote:
> On some really old hardware, the default timeout of 120 (which may even
> be reduced further on the command line) is insufficient.
>
> While such cases are specialist and (nowadays) relatively rare, it is
> still nice to be able to
Previously, systemd-user-sessions.service started after remote-fs.target.
If the user had any NFS mounts defined, this prevented logins until these
were processed.
If the user was using NFS for their home directories, this configuration
makes sense, but equally, the user may have remote mounts def
On some really old hardware, the default timeout of 120 (which may even
be reduced further on the command line) is insufficient.
While such cases are specialist and (nowadays) relatively rare, it is
still nice to be able to provide a method to increase the timeout
when needed.
Bug Link: https://b
Hiya,
Just some patches I've been carrying downstream for a while now. Would
be nice to get them upstreamed.
The first two are distro specific so nothing too crazy there.
The third is a udev patch that was discussed with Kay a while back, but
I forgot to upstream it prior to the udev merge. Here
This seems to have been a problem since mageia support was merged,
as upstream had changed how this bit worked without us realising.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index e0a2526..5f0b225 100644
--- a/configure.ac
+++
Do not wait for some of the Fedora units that we have traditionally not
waited for in Mageia or Mandriva before it.
---
units/mageia/prefdm.service | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/units/mageia/prefdm.service b/units/mageia/prefdm.service
index c8
26 matches
Mail list logo
