On Thu 20 Dec at 12:46:14 +0100 [email protected] said:
>
> This is actually documented explicitly, that we don't support this:
>
> http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities
>
> And I am pretty strongly of the oppinion that service-specific verbs
> should not be handle
On Thu, 20.12.12 11:37, Colin Guthrie ([email protected]) wrote:
> > FWIW, as previously mentioned, I'd love to see an explicitly supported
> > way to trigger a re-exec of a daemon. Currently I'm just relying on the
> > ability to send a custom signal to libvirt's virtlockd daemon. The problem
'Twas brillig, and Daniel P. Berrange at 20/12/12 10:44 did gyre and gimble:
> On Wed, Dec 19, 2012 at 11:46:13PM +0100, Lennart Poettering wrote:
>> On Wed, 28.11.12 22:41, Brandon Black ([email protected]) wrote:
>>
>>> The daemon's "fast restart" code does all of the expensive startup
>>> operat
On Wed, Dec 19, 2012 at 11:46:13PM +0100, Lennart Poettering wrote:
> On Wed, 28.11.12 22:41, Brandon Black ([email protected]) wrote:
>
> > The daemon's "fast restart" code does all of the expensive startup
> > operations in the new daemon first (e.g. parsing large data input), then
> > signals t
On Wed, 28.11.12 22:41, Brandon Black ([email protected]) wrote:
> The daemon's "fast restart" code does all of the expensive startup
> operations in the new daemon first (e.g. parsing large data input), then
> signals the existing daemon to shut itself down, waits for it to release
> its critical
On Fri, Nov 30, 2012 at 3:59 AM, Colin Guthrie wrote:
> It won't give you all the features above it should mean that no connections
> are lost in that window.
I don't think socket activation will do that. If systemd has spawned a
process for each connection, those will get shut down. If the serv
'Twas brillig, and Brandon Black at 29/11/12 04:41 did gyre and gimble:
> The daemon's "fast restart" code does all of the expensive startup
> operations in the new daemon first (e.g. parsing large data input), then
> signals the existing daemon to shut itself down, waits for it to release
> its cr
On Thu, Nov 29, 2012 at 11:36 AM, Alexander E. Patrakov
wrote:
> Brandon Black wrote:
> > The daemon's "fast restart" code does all of the expensive startup
> > operations in the new daemon first (e.g. parsing large data input), then
> This is not what a restart means in systemd world. What you d
On 11/29/2012 04:41 AM, Brandon Black wrote:
Hi all,
I'm trying to write a systemd.service unit file for an existing
well-behaved daemon that's used to managing itself. The daemon binary
doubles as its own controller for sysvinit-like command. For example
"foo start" launches a new daemo
Brandon Black wrote:
> The daemon's "fast restart" code does all of the expensive startup
> operations in the new daemon first (e.g. parsing large data input), then
> signals the existing daemon to shut itself down, waits for it to release
> its critical resources (e.g. sockets, pidfile), and fina
Hi all,
I'm trying to write a systemd.service unit file for an existing
well-behaved daemon that's used to managing itself. The daemon binary
doubles as its own controller for sysvinit-like command. For example "foo
start" launches a new daemon. "foo stop" stops an existing instance of the
dae
11 matches
Mail list logo
