keep other method for now, consider dropping later.
Supporting relative links here could be problematic as timezones in
/usr/share/zoneinfo are often themselves symlinks (and symlinks to
symlinks), so this implamentation only only support absolute links.
---
src/timedate/timedated.c | 28 ++
On Mon, 06.08.12 23:09, Kay Sievers ([email protected]) wrote:
>
> On Mon, Aug 6, 2012 at 10:49 PM, Daniel Drake wrote:
> > Hi,
> >
> > I thought I read somewhere that systemd offers a mechanism to set an
> > environment variable system-wide - i.e. the variable assignment will
> > be present in all
On Mon, Aug 6, 2012 at 3:09 PM, Kay Sievers wrote:
> systemctl set-environment ... ?
Maybe thats what I read about.
In this case I'm looking to set it in early boot though, so that it
affects all spawned processes from the very start. Is there a nice way
of doing this?
> But it's in almost all
On Mon, Aug 6, 2012 at 10:49 PM, Daniel Drake wrote:
> Hi,
>
> I thought I read somewhere that systemd offers a mechanism to set an
> environment variable system-wide - i.e. the variable assignment will
> be present in all the processes started by systemd.
>
> But I can't find where I read this, o
Hi,
I thought I read somewhere that systemd offers a mechanism to set an
environment variable system-wide - i.e. the variable assignment will
be present in all the processes started by systemd.
But I can't find where I read this, or how to use it.
Does this functionality exist or am I getting co
Previously, if a service configured to restart automatically exceeds
its start limit, it entered the "inactive/dead" state. That seems
wrong to me, since there is nothing to indicate to the user that the
service has failed. This patch causes it to enter the failed state
instead.
---
src/core/ser
On Mon, 2012-08-06 at 16:39 +0200, Lennart Poettering wrote:
> On Fri, 03.08.12 17:33, shawn ([email protected]) wrote:
>
> Applied!
>
ha! clang didn't find that careless typo you fixed, while gcc points it
out. I call BS on the "better diagnostics".
> Note that we should be carefuly with
On Monday 06 Aug 2012 12:16:02 Lennart Poettering wrote:
> On Mon, 06.08.12 12:06, Kay Sievers ([email protected]) wrote:
> >
> > How about:
> > ExitStatusFailure=
> > ExitStatusSuccess=
>
> success and failure should be parititions of
> the exit status set, i.e. all exits that are not failure ar
On Mon, Aug 6, 2012 at 6:14 PM, Daniel P. Berrange wrote:
> On Mon, Aug 06, 2012 at 06:04:11PM +0200, Kay Sievers wrote:
>> On Mon, Aug 6, 2012 at 5:52 PM, Daniel P. Berrange
>> wrote:
>> > For libvirt, we (will soon) have a daemon (virtlockd) which maintains
>> > exclusive fcntl() based locks o
On Mon, Aug 06, 2012 at 06:04:11PM +0200, Kay Sievers wrote:
> On Mon, Aug 6, 2012 at 5:52 PM, Daniel P. Berrange
> wrote:
> > For libvirt, we (will soon) have a daemon (virtlockd) which maintains
> > exclusive fcntl() based locks on disk images/devices, on behalf of both
> > libvirtd and any run
On Mon, Aug 6, 2012 at 5:52 PM, Daniel P. Berrange wrote:
> For libvirt, we (will soon) have a daemon (virtlockd) which maintains
> exclusive fcntl() based locks on disk images/devices, on behalf of both
> libvirtd and any running QEMU or LXC instances. This is a safety critical
> daemon (hence se
For libvirt, we (will soon) have a daemon (virtlockd) which maintains
exclusive fcntl() based locks on disk images/devices, on behalf of both
libvirtd and any running QEMU or LXC instances. This is a safety critical
daemon (hence separate from libvirtd), to the extent that if the daemon
stops / cra
2012/8/3 Lennart Poettering :
> On Tue, 24.07.12 16:43, Lukas Nykryn ([email protected]) wrote:
>
> Maybe DontRestartExitStatus=? The libc calls the generalization of
> exit code and exit signal the "exit status", so that sounds like the
> best term to use here.
>
> And then people could write:
>
Lennart Poettering píše v Po 06. 08. 2012 v 16:52 +0200:
> On Mon, 06.08.12 16:45, Lukáš Nykrýn ([email protected]) wrote:
>
> > +if (!*set) {
> > +set_free(*set);
> > +*set = NULL;
> > +}
>
> You probably mean if (*set) here, not (!*set). But hone
On Mon, 06.08.12 16:47, Zbigniew Jędrzejewski-Szmek ([email protected]) wrote:
>
> On 08/06/2012 04:39 PM, Lennart Poettering wrote:
> > On Fri, 03.08.12 17:33, shawn ([email protected]) wrote:
> >
> > Applied!
> >
> > Note that we should be carefuly with adding additional erorr messages t
On Mon, 06.08.12 16:45, Lukáš Nykrýn ([email protected]) wrote:
> +if (!*set) {
> +set_free(*set);
> +*set = NULL;
> +}
You probably mean if (*set) here, not (!*set). But honestly I think this
bit should just go entirely as for most other settings
On 08/06/2012 04:39 PM, Lennart Poettering wrote:
> On Fri, 03.08.12 17:33, shawn ([email protected]) wrote:
>
> Applied!
>
> Note that we should be carefuly with adding additional erorr messages to
> the EXIT_SUCCESS/EXIT_FAILURE bits, since we might end up with two error
> messages instead
Lukáš Nykrýn píše v Po 06. 08. 2012 v 15:26 +0200:
> Lennart Poettering píše v Pá 03. 08. 2012 v 20:46 +0200:
> > On Tue, 24.07.12 16:43, Lukas Nykryn ([email protected]) wrote:
> >
> > > In some cases, like wrong configuration, restarting after error
> > > exit code does not help, so administrat
On Fri, 03.08.12 17:33, shawn ([email protected]) wrote:
Applied!
Note that we should be carefuly with adding additional erorr messages to
the EXIT_SUCCESS/EXIT_FAILURE bits, since we might end up with two error
messages instead of one, which is something we should try to avoid...
Lennart
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/03/2012 03:45 PM, Lennart Poettering wrote:
> On Mon, 30.07.12 17:13, Daniel J Walsh ([email protected]) wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> In containers we are blocking systemd from creating containers. If I try
>
Lennart Poettering píše v Pá 03. 08. 2012 v 20:46 +0200:
> On Tue, 24.07.12 16:43, Lukas Nykryn ([email protected]) wrote:
>
> > In some cases, like wrong configuration, restarting after error
> > exit code does not help, so administrator can specify RestartIgnoreCodes
> > which will not cause re
On 08/06/2012 01:19 PM, Lennart Poettering wrote:
> On Sat, 04.08.12 10:50, Bryan Kadzban ([email protected]) wrote:
>
>>
>> microcai wrote:
>>> 2012/8/4 Lennart Poettering :
On Tue, 24.07.12 22:45, Jonathan Callen ([email protected]) wrote:
> In the x32 ABI, syscall numbers
On Mon, Aug 6, 2012 at 1:16 PM, Lennart Poettering
wrote:
> On Mon, 06.08.12 12:06, Kay Sievers ([email protected]) wrote:
>> > Not sure if "Inhibit*" is maybe used somewhere already that would make
>> > this less desirable tho'.
>>
>> We have:
>> Restart=on-success | on-failure | ...
>>
>> Does th
On Mon, Aug 6, 2012 at 1:12 PM, Lennart Poettering
wrote:
> On Mon, 06.08.12 01:14, Colin Guthrie ([email protected]) wrote:
>
>>
>> 'Twas brillig, and Lennart Poettering at 03/08/12 19:46 did gyre and gimble:
>> > Maybe DontRestartExitStatus=? The libc calls the generalization of
>> > exit cod
On Sat, 04.08.12 10:50, Bryan Kadzban ([email protected]) wrote:
>
> microcai wrote:
> > 2012/8/4 Lennart Poettering :
> >> On Tue, 24.07.12 22:45, Jonathan Callen ([email protected]) wrote:
> >>
> >>> In the x32 ABI, syscall numbers start at 0x4000. Mask that
> >>> bit on x32 for l
On Mon, 06.08.12 12:06, Kay Sievers ([email protected]) wrote:
>
> On Mon, Aug 6, 2012 at 2:14 AM, Colin Guthrie wrote:
> > 'Twas brillig, and Lennart Poettering at 03/08/12 19:46 did gyre and gimble:
> >> Maybe DontRestartExitStatus=? The libc calls the generalization of
> >> exit code and exit sig
On Mon, 06.08.12 01:14, Colin Guthrie ([email protected]) wrote:
>
> 'Twas brillig, and Lennart Poettering at 03/08/12 19:46 did gyre and gimble:
> > Maybe DontRestartExitStatus=? The libc calls the generalization of
> > exit code and exit signal the "exit status", so that sounds like the
> >
Hi,
I have launched "systemd --user", created a bts.service file, added
'ConditionPathExists=' in the Unit section of my service. Then I
launched my service with 'systemctl --user start ...' and as the
path does not exist, the condition_test fails and the service is not
started.
Next I tried to
On Mon, Aug 6, 2012 at 2:14 AM, Colin Guthrie wrote:
> 'Twas brillig, and Lennart Poettering at 03/08/12 19:46 did gyre and gimble:
>> Maybe DontRestartExitStatus=? The libc calls the generalization of
>> exit code and exit signal the "exit status", so that sounds like the
>> best term to use here
2012/8/6 Colin Guthrie :
> 'Twas brillig, and Lennart Poettering at 03/08/12 19:46 did gyre and gimble:
>> Maybe DontRestartExitStatus=? The libc calls the generalization of
>> exit code and exit signal the "exit status", so that sounds like the
>> best term to use here.
>
> Would InhibitRestartExi
30 matches
Mail list logo
