Openvpn прекращает отвечать

Теперь я думаю, что это ошибка, связанная с тем, как при старте сервисы запускаются "ожидающим демоном" (т.е. сервисами, которые при старте дважды вилливают при старте). Я заметил, что если я использую натяжку на процесс, использующий возможности(7), то возможности также игнорируются. Я подозреваю, что upstart, для того, чтобы определить PID для ожидания, отслеживает службу, указанную с "ожидающим демоном" достаточно долго, чтобы получить PID, и это приводит к отказу механизма возможностей ядра. Таким образом, ошибка заключается в том, что возможности взаимодействуют с трассировкой процесса, и в том, что upstart использует трассировку процесса при запуске сервиса с "ожидающим демоном" (это предположение).

В качестве простого теста:

1. Напишите небольшую C PROGRAM для привязки к порту 443 (нельзя использовать интерпретируемый язык, например, питон с возможностями(7)).
2. Запустите его как не корневой, и увидите, что он не может быть привязан из-за отсутствия привилегий.
3. Установите возможность CAP_NET_BIND_SERVICE для вашей PROGRAM (в качестве корневого запуска setcap 'cap_net_bind_service+epi' PROGRAM)
4. Запустите его как не корневой, и посмотрите, что он теперь успешно работает.
5. Теперь запустите его с перетягиванием, и посмотрите, что он теперь неудачен.

(обратите внимание, что в шаге 3, строго говоря, набор унаследованных возможностей (i флаг) не нужно изменять для этого теста, но нужно для процесса, который forks(), например, мой демон).

Я напишу об этом в файл с ошибкой против ядра, так как ничто в man-странице возможностей(7) не говорит о том, что это не должно работать с трассировкой процесса.