Chield scshs not killed?

[michael-heerdegen]

Hi,

I use a scsh script to generate and regularly refresh a desktop background image showing weather stuff. The template looks like this:

#!/usr/local/bin/scsh \
-e main -s
!#

(define composite-bitmap "composite.gif")
(define working-dir (resolve-file-name "~/download/"))

(define download-regularly
  (lambda (mins url)
    (& (begin (let loop ()
                (with-cwd working-dir (run (wget -N --no-cache ,url)))
                (run (sleep ,(* 60 mins)))
                (loop))))))

(define (main . _)
  (run (sleep 60))
  (with-cwd working-dir
            (download-regularly
             10
             "http://www.wetterzentrale.de/pics/D2u.jpg")
            ...
            (let loop ()
              (run (composite -geometry 636x446+5+5
                              D2u.jpg ,composite-bitmap ,composite-bitmap))
              ...
              (run (display -window root ,composite-bitmap))
              (run (sleep ,(* 60 5)))
              (loop))))

The problem: when my xsession has been finished and the above script has been terminated, all the chield processes downloading stuff are still alive! Not good. Is this expected? What can I do to prevent this? Thanks and greetings!

[roderyc]

I can reproduce this; I'll investigate and update this when I have more info.

[michael-heerdegen]

Ok, thanks. No need to hurry.

[roderyc]

alright, so after research, I think I'll treat this more as a feature request than a bug.

This sort of thing won't usually happen in traditional shells because when they're about to stop, they try to send SIGHUP to any children in their job table (if they can). This is very tied to the job table feature though, i.e. the mechanism behind the commands jobs, bg, and fg in say, bash. Since scsh hasn't ever offered an equivalent mechanism (note that process reaping serves a different purpose), I don't consider this a bug. The previous version of scsh would behave the same. Furthermore, if you were to do something equivalent in a traditional shell, you would still have unterminated child processes if that shell were killed with SIGKILL, or another signal it can't setup a signal handler for.

The calls to sleep in your script is a red flag to me. I wouldn't consider sleep a good way to schedule work to be done on an interval, which is what you want. You could do that more robustly in several ways; I would use whatever command scheduling mechanism your OS offers, like cron.

[michael-heerdegen]

Roderic Morris notifications@github.com writes:

alright, so after research, I think I'll treat this more as a feature request than a bug.

That's ok by me.

There could be some kind of scsh-exit-hook where you could push something like (lambda () (kill-chield-scsh ... )) to.

This sort of thing won't usually happen in traditional shells because when they're about to stop, they try to send SIGHUP to any children in their job table (if they can). This is very tied to the job table feature though, i.e. the mechanism behind the commands jobs, bg, and fg in say, bash. Since scsh hasn't ever offered an equivalent mechanism (note that process reaping serves a different purpose), I don't consider this a bug. The previous version of scsh would behave the same. Furthermore, if you were to do something equivalent in a traditional shell, you would still have unterminated child processes if that shell were killed with SIGKILL, or another single it can't setup a signal handler for.

I see your point. OTOH, the syntax for sub scshs, which makes their code an integral part of the program, would make me expect the behavior I want.

The calls to sleep in your script is a red flag to me. I assume those are usually the processes you see live on after scsh dies.

Not only, I also see their parents, the shsh instances started by the original scsh script.

I wouldn't consider sleep a good way to schedule work to be done on an interval, which is what you want. You could do that more robustly in several ways; I would use whatever command scheduling mechanism your OS offers, like cron.

Maybe scsh is not a good solution, but using Cron is IMHO not better. This is just about the desktop background of a particular user, and needing to do system administration for that task seems inappropriate.

I understand what you mean, but I also think that when you where the Cron developer, you probably would recommend to use something like scsh for that task ;-)

[roderyc]

I don't know what OS you're using, but modern crons / command schedulers allow scheduling tasks by a regular user. It's not really a system administration task; if you want something to be run periodically, it's the unix tool that's purpose built for that.

Trust me, as someone who writes code that has to worry about concurrency / scheduling on a daily basis, you don't want to have a process sleep for a fixed amount of time when it could just be started exactly when it's needed.

[michael-heerdegen]

Roderic Morris notifications@github.com writes:

I don't know what OS you're using, but modern crons / command schedulers allow scheduling tasks by a regular user. It's not really a system administration task; if you want something to be run periodically, it's the unix tool that's purpose built for that.

I use Debian. Thanks for the hint, I'll try that.

Trust me, as someone who writes code that has to worry about concurrency / scheduling on a daily basis, you don't want to have a process sleep for a fixed amount of time when it could just be started exactly when it's needed.

I always try to cope with as few tools as possible (that's why I use Emacs). Of cause that's the opposite of the Unix philosophy, and sometimes, it's just stupid to avoid learning new good tools...

[samliddicott]

Cron is the wrong tool if it only needs to run when the user is logged in.

Sam On 4 May 2014 04:05, "Roderic Morris" notifications@github.com wrote:

I don't know what OS you're using, but modern crons / command schedulers allow scheduling tasks by a regular user. It's not really a system administration task; if you want something to be run periodically, it's the unix tool that's purpose built for that.

Trust me, as someone who writes code that has to worry about concurrency / scheduling on a daily basis, you don't want to have a process sleep for a fixed amount of time when it could just be started exactly when it's needed.

— Reply to this email directly or view it on GitHubhttps://github.com/scheme/scsh/issues/22#issuecomment-42122650 .

[michael-heerdegen]

samliddicott notifications@github.com writes:

Cron is the wrong tool if it only needs to run when the user is logged in.

Thanks for your opinion.

Probably there just is no simple straightforward solution for what I want.

One reason why I chose scsh for that task was because I can transparently "paste" strings into the sub scshs (via implicit backquoting). This makes it easy to make modify the thing e.g. when the url of an image changes.