[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29992: 'postgres' service doesn't stop

From: Danny Milosavljevic
Subject: bug#29992: 'postgres' service doesn't stop
Date: Fri, 12 Jan 2018 22:42:42 +0100

Hi Catonano,

> When I run Tryton myself, I use this line:
> trytond -c trytond.conf
> this command doesn' t return a prompt

Does it stay in foreground with the tryton service, too?  It shouldn't do that 
for the service, see below.

make-forkexec-constructor should takes a pid-file argument which is supposed to 
refer to a file that trytond creates.  If that isn't specified, shepherd will 
default to the pid of the child process of shepherd that did the exec().  So it 
shouldn't have tryton in foreground in any case.

Note: make-forkexec-constructor also has a #:log-file keyword argument - which 
is handy for debugging.

> So, in order to stop Tryton I simply press Ctrl-C
> In the definition of my sevice, I use
> #~(make-kill-destructor)
> to stop the Tryton service
> But I copied this from other services, I don't know what
> "make-kill-destructor" does

(define make-kill-destructor
  (lambda* (#:optional (signal SIGTERM))
    (lambda (pid . args)
      (kill pid signal)

So it sends SIGTERM to the process.

What happens when you send SIGTERM manually ("kill -TERM ...")?

> My Trytond service is not working anyway, I launch a vm with my service
> running in it, I test  it with the client, I see it doesn't work, I stop it
> and then I'd like to launch it by hand to see something more

You can try finding its pid with "ps -ef |grep tryton" and then compare their 
/proc/<pid> trees (manually started vs. service-started).

In your screenshot, that would be /proc/411, especially /proc/411/fd and its 
signal mask (in /proc/411/status).

> But then, because a tryton-real daemon is still running, the socket for
> that address is already bound, as you can see in the picture

That's good then.

Try "netstat -lpn | grep 411" (or whatever the pid is now) to find out whether 
it's actually listening.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]