Summary: | hsh-run --no-wait-lock option unclear | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | ildar <ildar> |
Component: | hasher | Assignee: | Dmitry V. Levin <ldv> |
Status: | NEW --- | QA Contact: | qa-sisyphus |
Severity: | minor | ||
Priority: | P5 | CC: | at, glebfm, ldv, neurofreak-alt, placeholder |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
А текст ошибки будет? да, извините,
> $ hsh-run --no-wait-lock uname
> hsh-run: working directory /tmp/.private/ildar/hasher' is already locked by pid=4157078.
> 4157078 pts/4 S+ 0:00 /bin/sh -ef /usr/bin/hsh-run --mountpoints=/proc,/d
> hsh-run: Unable to lock working directory /tmp/.private/ildar/hasher'
Изначально hasher работал в режиме --no-wait-lock, сами параметры --wait-lock и --no-wait-lock появились только в версии 1.2.8, а начиная с версии 1.3.0 поведение по-умолчанию поменялось с --no-wait-lock на --wait-lock. У некоторых утилит hasher есть параметр --no-lock, он используется другими утилитами hasher, которые заботятся о блокировках первыми. окей, но это не проливает свет на то, как оно работает. А фактически опция не выключает блокировку, а только меняет поведение этой блокировки: ожидание или ошибка. Мне кажется логичным, что --wait-lock включает ожидание блокировки, а --no-wait-lock, наоборот, выключает ожидание блокировки. (Ответ для Dmitry V. Levin на комментарий #5) > Мне кажется логичным, что --wait-lock включает ожидание блокировки, а > --no-wait-lock, наоборот, выключает ожидание блокировки. мне тоже это кажется логичным. Но мне не очевидно, что, выключив ожидание блокировки, hsh-run валится с ошибкой, а не выполняет данную ему команду. |
документация говорит: > --no-wait-lock > do not wait for workdir and hasher-priv locks ($lock_nowait); я сначала думал, что hsh-run будет просто игнорировать лок. Но оказалось, что он выбрасывает ошибку и не работает. Надо бы исправить документацию, если я тут правильно всё понял.