On Tue, 21.04.15 13:25, Daniel Drake (dr...@endlessm.com) wrote:
> There's a comment in unit_kill_context() which looks relevant here:
>
> /* FIXME: For now, we will not wait for the
> * cgroup members to die, simply because
>
On Mon, Apr 20, 2015 at 6:29 PM, Lennart Poettering
wrote:
> Sure, we don't want to keep track of which processes we already
> killed, to distuingish them from the processes newly created in the
> time between our sending of SIGTERM and receiving SIGCHLD for the main
> process.
>
> We assume that
On Mon, 20.04.15 18:13, Daniel Drake (dr...@endlessm.com) wrote:
> >> 3. gdm simple-slave's signal handler triggers, which causes the
> >> mainloop to exit, and it starts to kill and wait for the X server
> >> death. I'm not exactly sure why, but quitting the glib mainloop also
> >> causes the sig
On Mon, Apr 20, 2015 at 6:04 PM, Lennart Poettering
wrote:
>> I have stepped through and I think that systemd is being too
>> aggressive. Still running with the default KillMode=cgroup, here is
>> what happens:
>>
>> 1. service_enter_stop() is entered which calls:
>> service_enter_
On Mon, 20.04.15 13:16, Daniel Drake (dr...@endlessm.com) wrote:
> On Mon, Apr 20, 2015 at 9:04 AM, Lennart Poettering
> wrote:
> > maybe the main gdm process is not the one waiting, but a worker
> > process is, and the main process kills the worker process without the
> > worker process handling
Daniel Drake endlessm.com> writes:
>
> So, moments after sending 2 SIGTERMs, SIGKILL is sent to all gdm
> processes. There does not seem to be any consideration of giving the
> process some time to respond to SIGTERMs, nor the fact that I have
> hacked gdm.service to have SendSIGKILL=no as an ex
On Mon, Apr 20, 2015 at 9:04 AM, Lennart Poettering
wrote:
> maybe the main gdm process is not the one waiting, but a worker
> process is, and the main process kills the worker process without the
> worker process handling that nicely?
Not really. I removed all the process-killing code from gdm a
On Mon, 20.04.15 08:54, Daniel Drake (dr...@endlessm.com) wrote:
> gdm git does have KillMode=mixed, but the slightly old gdm I'm running
> here also does not have any KillMode assignment.
KillMode=mixed means that systemd will SIGKILL all cgroup member
processes before "stop" returns.
>
> I'm
On Mon, Apr 20, 2015 at 8:24 AM, Lennart Poettering
wrote:
> On Sun, 19.04.15 09:34, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>
>> В Fri, 17 Apr 2015 14:04:18 -0600
>> Daniel Drake пишет:
>>
>> > Hi,
>> >
>> > I'm investigating why "systemctl stop gdm; Xorg" usually fails. The
>> > new X pro
On Sun, 19.04.15 09:34, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> В Fri, 17 Apr 2015 14:04:18 -0600
> Daniel Drake пишет:
>
> > Hi,
> >
> > I'm investigating why "systemctl stop gdm; Xorg" usually fails. The
> > new X process complains that X is still running.
> >
> > Here's what I think
On Fri, 17.04.15 14:04, Daniel Drake (dr...@endlessm.com) wrote:
> I'm investigating why "systemctl stop gdm; Xorg" usually fails. The
> new X process complains that X is still running.
Have you checked what precisely fails? What's the error message you
are getting? What is the actual failing rou
В Fri, 17 Apr 2015 14:04:18 -0600
Daniel Drake пишет:
> Hi,
>
> I'm investigating why "systemctl stop gdm; Xorg" usually fails. The
> new X process complains that X is still running.
>
> Here's what I think is happening:
>
> 1. systemd sends SIGTERM to gdm to stop the service
>
> 2. gdm exits
Hi,
I'm investigating why "systemctl stop gdm; Xorg" usually fails. The
new X process complains that X is still running.
Here's what I think is happening:
1. systemd sends SIGTERM to gdm to stop the service
2. gdm exits - it has a simple SIGTERM handler which just quits the
mainloop without doi
13 matches
Mail list logo
