Will service [a] block there when system shudown ?
>>>
>>> Default execution is synchronous, so yes, it will block.
>> even stop with "systemctl stop"? it looks kinda stopping manually.
>> still check the dependence ?
>>
>> do you have some way to let it not block, like some params of systemct
On Fri, 05.08.16 10:26, Andrei Borzenkov ([email protected]) wrote:
> > Everything happens asynchronously and systemd notices that the
> > filesystem has been mounted only through mountinfo.
>
> Yes, this is second real life case after ZFS which does not fit in
> rather simplistic model. We pro
On Fri, 05.08.16 12:33, Dr. Werner Fink ([email protected]) wrote:
> > Yeah, to make this clear: I do not blame libvirt for this borkedness
> > at all. I blame the kernel.
>
> Hmmm ... IMHO it is useless to pass the buck from kernel to user space
> as well do the same from user space back to kernel.
On Fri, Aug 5, 2016 at 2:46 PM, Xin Long wrote:
> Hi, Andrei:
> On Fri, Aug 5, 2016 at 7:13 PM, Andrei Borzenkov wrote:
>> On Fri, Aug 5, 2016 at 2:01 PM, Xin Long wrote:
>>> When system shutdown, service [a] try to kill service [b] with 'systemctl
>>> stop',
>>> but we define the dependence th
Hi, Andrei:
On Fri, Aug 5, 2016 at 7:13 PM, Andrei Borzenkov wrote:
> On Fri, Aug 5, 2016 at 2:01 PM, Xin Long wrote:
>> When system shutdown, service [a] try to kill service [b] with 'systemctl
>> stop',
>> but we define the dependence that [b] must die after [a].
>>
>> Will service [a] block t
On Fri, Aug 5, 2016 at 2:01 PM, Xin Long wrote:
> When system shutdown, service [a] try to kill service [b] with 'systemctl
> stop',
> but we define the dependence that [b] must die after [a].
>
> Will service [a] block there when system shudown ?
Default execution is synchronous, so yes, it wil
When system shutdown, service [a] try to kill service [b] with 'systemctl stop',
but we define the dependence that [b] must die after [a].
Will service [a] block there when system shudown ?
___
systemd-devel mailing list
[email protected]
On Fri, Aug 05, 2016 at 11:07:50AM +0200, Lennart Poettering wrote:
> On Thu, 04.08.16 16:19, Cedric Bosdonnat ([email protected]) wrote:
>
> > Hi Lennart and Werner,
> >
> > On Wed, 2016-08-03 at 16:56 +0200, Lennart Poettering wrote:
> > > On Wed, 03.08.16 14:46, Dr. Werner Fink (werner at su
Hi,
On 05/08/2016 09:26, Andrei Borzenkov wrote:
> In this case pragmatic solution is to order your service after mmfsd
> startup, assuming your filesystems are configured to be automounted
I already have such a dep in place, but due to the asynchronous nature
of GPFS the mount can (and does) hap
On Fri, Aug 05, 2016 at 12:33:21PM +0200, Dr. Werner Fink wrote:
> On Fri, Aug 05, 2016 at 11:07:50AM +0200, Lennart Poettering wrote:
> > On Thu, 04.08.16 16:19, Cedric Bosdonnat ([email protected]) wrote:
> >
> > > Hi Lennart and Werner,
> > >
> > > On Wed, 2016-08-03 at 16:56 +0200, Lennart
On Thu, 04.08.16 16:19, Cedric Bosdonnat ([email protected]) wrote:
> Hi Lennart and Werner,
>
> On Wed, 2016-08-03 at 16:56 +0200, Lennart Poettering wrote:
> > On Wed, 03.08.16 14:46, Dr. Werner Fink (werner at suse.de) wrote:
> > > problem with v228 (and I guess this is also later AFAICS fro
Отправлено с iPhone
> 4 авг. 2016 г., в 23:00, Matteo Panella
> написал(а):
>
> Hi,
>
>> On 04/08/2016 16:43, Mantas Mikulėnas wrote:
>> Then add an After= instead. Unit ordering is already specified
>> separately from dependencies.
>
> That does not work, unfortunately: since the entry in
12 matches
Mail list logo
