| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
This cannot completely guard against a runaway log event, and only runs
every hour anyway, but it should avoid most problems with very
long-running, active assistants using up too much space.
|
| |
|
|
|
|
|
|
| |
It used to not log to daemon.log when a repository was first created, and
when starting the webapp. Now both do. Redirecting stdout and stderr to the
log is tricky when starting the webapp, because the web browser may want to
communicate with the user. (Either a console web browser, or web.browser = echo)
This is handled by restoring the original fds when running the browser.
|
| | |
|
| |
|
|
|
| |
Display it before daemon forks, so it's not shown after the shell prompt
returns.
|
| | |
|
| |
|
|
|
|
|
|
| |
This prevents multiple runs of the assistant in the foreground, and lets
--stop stop foregrounded runs too.
The webapp firstrun case also now writes a pid file, once it's made the git
repo to put it in.
|
| |
|
|
| |
Useful for testing..
|
| |
|
|
| |
Also, starts the assistant if it wasn't already running.
|
| | |
|
| |
|
|
| |
need to truncate, or part of previous longer pid may be left after writing
|
| | |
|
| | |
|
| |
|
|
|
| |
Ok, that's odd.. opening it before fork breaks the locking.
I don't understand why.
|
| |
|
|
|
| |
Writes pid to a file. Is supposed to take an exclusive lock, but that's not
working, and it's too late for me to understand why.
|
| |
|
Joey Hess