On Mon, Feb 04, 2013 at 03:56:26PM +0100, Eelco Dolstra wrote:
> Nscd expects that an NSS module's gethostbyname4_r function returns
> its first result in the pre-allocated gaih_addrtuple denoted by **pat.
> (See nscd/aicache.c in the Glibc sources.) However, nss-myhostname
> doesn't fill in **pat
On Tue, Feb 05, 2013 at 01:43:10AM +0100, Mirco Tischler wrote:
> ---
> src/journal/coredump.c | 41 ++---
> 1 file changed, 10 insertions(+), 31 deletions(-)
Applied.
Zbyszek
___
systemd-devel mailing list
systemd-de
On Mon, Feb 04, 2013 at 03:13:24PM +0100, Mirco Tischler wrote:
> I can't find a reason why we shouldn't try to output messages for other
> unit types than .service, .socket, .mount and .swap as well. It's probably
> a leftover from before we started logging UNIT= from inside PID 1.
> ---
> src/sh
On Mon, Feb 04, 2013 at 03:13:23PM +0100, Mirco Tischler wrote:
> ---
> src/journal/coredump.c | 9 ++---
> src/shared/logs-show.c | 18 +++---
> 2 files changed, 21 insertions(+), 6 deletions(-)
Applied.
Zbyszek
___
systemd-devel maili
On Tue, Feb 05, 2013 at 02:43:32PM +0100, Michael Biebl wrote:
> 2013/2/5 Colin Walters :
> > On Tue, 2013-02-05 at 13:10 +0100, Kay Sievers wrote:
> >
> >> We do not want to place shared libraries with private APIs in the
> >> system. Other people might rely on stuff which we can never track.
> >
On Mon, Feb 04, 2013 at 03:01:23PM +0100, Umut Tezduyar wrote:
> Only set source for freshly created .mounts coming from
> mountinfo file.
Doesn't seem to apply anymore...
Zbyszek
> ---
> src/core/mount.c | 12 +++-
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/s
On Wed, Feb 6, 2013 at 4:21 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> current docs specify that %s means the shell of the user configured
> with User= or the user running systemd. However, it actually often
> returns /bin/sh. What is the intended behaviour?
it should reflect the passwd entry, whic
Hi,
current docs specify that %s means the shell of the user configured
with User= or the user running systemd. However, it actually often
returns /bin/sh. What is the intended behaviour?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freede
On 06/02/13 00:55, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Feb 05, 2013 at 11:45:10PM +, Steven Hiscocks wrote:
On 05/02/13 23:00, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Feb 05, 2013 at 09:22:46PM +, Steven Hiscocks wrote:
On 05/02/13 02:49, Zbigniew Jędrzejewski-Szmek wrote:
H
Fixes this bug:
alxchk > systemctl --user set-environment A=B
alxchk > systemctl --user show-environment | grep ^A=
A=B
alxchk > systemctl --user daemon-reexec
alxchk > systemctl --user show-environment | grep ^A=
alxchk >
---
src/core/manager.c | 18 ++
1 file changed, 18 insertio
Recently, Fedora shipped an update which starts the Open vSwitch service
on demand -- whenever an Open vSwitch bridge or port is "ifup'ed". In
theory, I should now be able to simply write traditional ifcfg-* files
for all of my interfaces and use the "network" service to start them.
Unfortunately
On Wed, Feb 6, 2013 at 1:18 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> Hm, but couldn't we add field for the sequence start?
If necessary. I'd like to keep it separate from the recurrence rule, though.
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
_
On Tue, Feb 05, 2013 at 11:25:47AM -0800, David Strauss wrote:
> On Mon, Feb 4, 2013 at 6:49 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > What about renaming Journalctl to Journal? It doesn't really control
> > anything :)
>
> Neither does the actual journalctl. :-)
True.
> But, systemd's namin
On Wed, Feb 06, 2013 at 12:25:57PM -0800, David Strauss wrote:
> On Wed, Feb 6, 2013 at 4:54 AM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > I'm probably missing something, but if a start date and a count are set,
> > then it should be possible to calculate the next event (or if all are
> > now past)
On Wed, Feb 6, 2013 at 4:54 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> I'm probably missing something, but if a start date and a count are set,
> then it should be possible to calculate the next event (or if all are
> now past) based on this data?
Yes. I'm just saying that because systemd doesn't t
Hi,
> I actually don't care that much whether this option gets introduced or
> not.
And I don't either by now. I've scratched my itch by calling setleds(1) from
rc.local by now, so do whatever you want with the patch.
Cheers
Matthias
___
systemd-devel
On Wed, Feb 6, 2013 at 4:03 PM, David Herrmann
wrote:
> I actually don't care that much whether this option gets introduced or
> not. The race-condition is pretty hard to trigger and even if you
> trigger it, it doesn't cause any big problems but only wrongly lit
> LEDs.
We should really step ba
Hi Matthias
On Wed, Feb 6, 2013 at 3:12 PM, Matthias Berndt wrote:
> No. I had seen a similar hint toward the end of the console_ioctl man page and
> decided to ignore it. These ioctls have been around forever, tools like
> setleds(1) rely on them. We know how Linus feels about breaking userspace
Hi David,
that you for your feedback.
> > The ioctls return 0 and don't affect X. After switching back to text mode,
> > the changes do take effect.
>
> How do you know that?
I've tried it and this is the behaviour I've observed.
> Looking at the kernel code it seems that the
> LEDs are immedia
On Wed, Feb 6, 2013 at 2:14 PM, David Herrmann
wrote:
> All in all, it sounds nice to have this option at vconsole.conf, but
> it affects _global_ state, not _local_ VT state so other users might
> be really confused if they wonder why their Xserver starts with
> NUMLOCK enabled and they cannot f
2013/2/4 Lennart Poettering :
> On Fri, 01.02.13 10:27, Stef Bon (stef...@gmail.com) wrote:
>
>> I think I misunderstood the assigning of a device to a seat.
>> The creation of a seat is not done by the udev rules, what I assumed
>> first,
>
> It is done via udev rules.
>
>> but only some propertie
Hi Matthias
On Wed, Feb 6, 2013 at 12:51 AM, Matthias Berndt wrote:
> Hi Lennart,
>
>> It should suffice to invoke your set_modifiers() function in some
>> wrapper function set_modifiers_on_all_vcs() which internally just runs
>> VT_GETSTATE and iterates over all allocated VCs. See
>> font_copy_t
On Wednesday 06 February 2013 13:14:00 Kay Sievers wrote:
> This will all be implemented in the future, and work a bit like
> anacron, it just isn't done yet.
>
> Kay
Thanks. It's nice to know that it's intended to be implemented in the future.
Jan
___
On Wed, Feb 06, 2013 at 12:37:51AM -0800, David Strauss wrote:
> And, to bring this thread full-circle:
>
> [Timer]
> Recurrence=FREQ=monthly;BYMONTHDAY=-1
>
> That will run on the last day of each month.
>
> On Wed, Feb 6, 2013 at 12:34 AM, David Strauss wrote:
> > Oh, one other current limita
On Wed, Feb 6, 2013 at 12:49 PM, Jan Janssen wrote:
> On Tuesday 05 February 2013 11:19:29 David Strauss wrote:
>> On Tue, Feb 5, 2013 at 8:54 AM, Jan Janssen wrote:
>> > It would be nice if timers got scheduled based on their last time they got
>> > triggered.
>>
>> They have always supported th
On Tuesday 05 February 2013 11:19:29 David Strauss wrote:
> On Tue, Feb 5, 2013 at 8:54 AM, Jan Janssen wrote:
> > It would be nice if timers got scheduled based on their last time they got
> > triggered.
>
> They have always supported this, even before we added calendar-based
> support. Check ou
The getty@.service used to specifically enable a getty@tty1.service
under getty.target when enabled.
Modern versions of systemd allow commands such as:
systemctl enable getty@tty2.service
which automatically create the correct symlink if the
Install rule permits it.
This changes the default gett
Hi Matthias,
'Twas brillig, and Matthias Berndt at 06/02/13 01:18 did gyre and gimble:
> I've modified the patch again so that it also sets the default state of the
> LED flags to the configued values. Otherwise it'd switch NumLock off again
> when you type reset into the console.
Just as point
We have our configuration management tools stagger jobs based on
stable criteria like the machine ID.
On Wed, Feb 6, 2013 at 1:13 AM, Olav Vitters wrote:
> Feature request: allow to randomly delay a scheduled job
>
> Why:
> I have various cron jobs that run every 20min on various VMs + servers.
>
Feature request: allow to randomly delay a scheduled job
Why:
I have various cron jobs that run every 20min on various VMs + servers.
All servers are synched with NTP. What happens is that if they use some
shared resource (e.g. an LDAP server), the load spikes on that LDAP
server spikes every 20mi
And, to bring this thread full-circle:
[Timer]
Recurrence=FREQ=monthly;BYMONTHDAY=-1
That will run on the last day of each month.
On Wed, Feb 6, 2013 at 12:34 AM, David Strauss wrote:
> Oh, one other current limitation is that it doesn't let you specify a
> time zone since the code just uses th
Oh, one other current limitation is that it doesn't let you specify a
time zone since the code just uses the current time (effectively in
UTC) for DTSTART. We could support actual time zones if necessary by
having an additional field like TimeZone= that gets passed into the
"next event" calculation
Here is a version that is tested and, with review, I think ready to
commit. This adds a unit test to exercise the "next event" logic,
to/from string wrappers, and validity checks.
This represents a near superset of existing scheduling. For example:
* "FREQ=minutely" will execute every minute, st
33 matches
Mail list logo
