По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
REST API – один из самых распространенных типов доступных веб-сервисов, но проектировать их сложно. Они позволяют разным клиентам, включая браузер, настольные приложения, мобильные приложения и практически любое устройство с подключением к Интернету, взаимодействовать с сервером. Именно поэтому очень важно правильно проектировать REST API, чтобы в будущем не было проблем.
Создание API с нуля может оказать непосильной задачей из-за большого количества вещей, которые необходимо учесть – от базовой безопасности до использования правильных методов HTTP, реализации аутентификации, определения того, какие запросы и ответы среди многих других принимаются и возвращаются. В этой статье я очень постарался сжать материал в 15 пунктов с важными рекомендациями, которые позволят создать хороший API. Все рекомендации никак не зависят от языка, поэтому потенциально применимы к любой платформе или технологии.
1. Обязательно используйте имена существительные в названиях путях к конечным точкам
Вам всегда следует использовать имена существительные, которые обозначают объект, который вы извлекаете или которым вы манипулируете. В качестве имени пути всегда предпочтительнее использовать множественное число. Избегайте использования глаголов в названиях путях к конечным точкам, потому что наш метод HTTP-запроса уже является глаголом и по сути не добавляет никакой новой информации.
Действие должно быть произведено с помощью методов HTTP-запроса. Наиболее распространенными являются методы GET, POST, PATCH, PUT и DELETE.
GET извлекает ресурсы
POST отправляет новые данные на сервер
PUT/PATCH модифицируют уже существующие данные
DELETE удаляет данные
Глаголы сопоставляются с функциями CRUD (Create, read, update и delete).
Помня об этих принципах, мы должны создавать маршруты типа GET /books для получения списка книг, а не GET /get-books или GET /book. Аналогично, POST /books - для добавления новой книги, PUT /books/:id - для модификации полных данных книги с заданным идентификатором (id), а PATCH /books/:id обновляет частичные изменения в книге. И наконец, DELETE /books/:id предназначен для удаления существующей книги в заданным идентификатором.
2. JSON как основной формат отправки и получения данных
Несколько лет назад прием и ответы на запросы API выполнялись в основном в XML. Но сейчас «стандартным» форматом для отправки и получения данных API в большинстве приложений стал JSON. Поэтому наш второй пункт рекомендует убедиться, что конечные точки возвращают формат данных JSON в качестве ответа, а также при приеме информации через полезную нагрузку HTTP-сообщений.
Несмотря на то, что FormData хорошо подходит для отправки данных от клиента, особенно если нам нужно отправлять файлы, они не очень подходят для текста и чисел. Нам не нужны FormData для их передачи, так как в большинстве фреймворков можно передавать JSON непосредственно на стороне клиента. При получении данных от клиента нам необходимо убедиться, что клиент правильно интерпретирует данные JSON, и для этого при выполнении запроса в заголовке ответа Content-Type должен быть установлен на application/json.
Стоит еще раз упомянуть исключение, когда мы пытаемся отправлять и получать файлы между клиентом и сервером. В этом конкретном случае нам необходимо обрабатывать файл ответа и отправлять FormData с клиента на сервер.
3. Используйте коды состояний HTTP
Коды состояний HTTP всегда полезно использовать для того, чтобы указать на выполнение или невыполнение запроса. Не используйте слишком много кодов состояний и всегда используйте одни и те же коды для одних и тех же результатов в API. Вот некоторые примеры:
200 – общее выполнение
201 – успешное создание
400 – неверные запросы от клиента, такие как неверные параметры
401 – несанкционированные запросы
403 – отсутствие прав доступа к ресурсам
404 – отсутствуют ресурсы
429 – слишком много запросов
5хх – внутренние ошибки (их следует избегать насколько это возможно)
В зависимости от ситуаций их может быть и больше, но ограничение количества кодов состояний помогает клиенту использовать более предсказуемый API.
4. Возвращайте стандартизированные сообщения
Помимо использования кодов состояния HTTP, которые указывают на результат запроса, всегда используйте стандартизированные ответы для аналогичных конечных точек. Пользователи могут всегда рассчитывать на одинаковую структуру и действовать соответственно. Это также относится к статусу, указывающему на выполнение запроса, и сообщениях об ошибках. В случае выборки коллекций придерживайтесь определенного формата, независимо от того, включает ли тело ответа массив данных, подобный этому:
[
{
bookId: 1,
name: "The Republic"
},
{
bookId: 2,
name: "Animal Farm"
}
]
или вот такой комбинированный ответ:
{
"data": [
{
"bookId": 1,
"name": "The Republic"
},
{
"bookId": 2,
"name": "Animal Farm"
}
],
"totalDocs": 200,
"nextPageId": 3
}
Здесь рекомендация заключается в том, чтобы быть последовательным независимо от того, какой подход вы выберете для этого. Аналогичное поведение должно быть реализовано при извлечении объекта, а также при создании и модификации ресурсов, которым обычно рекомендуется возвращать последний экземпляр объекта.
// Ответ после успешного вызова POST /books
{
"bookId": 3,
"name": "Brave New World"
}
Хоть это и никак не навредит, но все же излишнем будет включать универсальное сообщение, например, «Книга успешно создана», так как это уже следует из кода состояния HTTP.
И последнее, но не менее важное: при наличии стандартного формата ответа коды ошибок также важны (и даже более важные). Это сообщение должно включать информацию, которую клиент может использовать для представления ошибок конечному пользователю, а соответственно, это должно быть не общее предупреждение, такое как «то-то пошло не так», которого следует избегать, насколько это возможно. Вот пример:
{
"code": "book/not_found",
"message": "A book with the ID 6 could not be found"
}
Опять же, нет необходимости включать код состояния в содержимое ответа, но полезно определить набор кодов ошибок, таких как book/not_found, чтобы пользователь мог сопоставить их с разными строками и создать свое собственное сообщение об ошибке для конечного пользователя. В частности, для сред разработки или промежуточных сред может показаться правильным также включить стек ошибок в ответ с целью помочь в отладке ошибок. Но не включайте те, что находятся в промышленной эксплуатации, так как это создаст угрозу безопасности, раскрывая незапланированную информацию.
5. Используйте разбиение на страницы, фильтрацию и сортировку при выборе коллекций записей
Как только будет создана конечная точка, которая возвращает список элементов, необходимо будет установить разбиение на страницы. Обычно коллекции со временем растут, поэтому важно всегда следить за тем, чтобы возвращалось ограниченное и контролируемое количество элементов. Справедливо будет позволить пользователям API выбирать, сколько объектов получить, но всегда полезно заранее определить число и установить для него максимум. Основная причина, почему нужно это сделать, заключается в том, что для возврата огромного массива данных потребуется очень много времени и большая пропускная способность.
Для реализации нумерации страниц есть два хорошо известных способа: skip/limit или keyset. Первый вариант обеспечивает более удобный для пользователя способ извлечения данных, но обычно он менее эффективен, так как базы данных сканируют множество документов для извлечения нужных записей. Мне больше нравится второй вариант. Разделения на страницы с помощью keyset получает идентификатор (id) в качестве ссылки для «вырезания» коллекции или таблицы с условием без сканирования записей.
Также API должны предоставлять фильтры и возможности сортировки, которые упрощают способы получения данных. Частью решения повышения производительности являются индексные базы данных, которые позволяют максимизировать производительность при помощи шаблонов доступа, которые применяются с фильтрами и параметрами сортировки.
При проектировании API эти свойства разбиения на страницы, фильтрации и сортировки определяются как параметры запроса в URL-адресе. Например, если вы хотим получить информацию о первых 10 книгах, принадлежащих к категории «роман», то наша конечная точка будет выглядеть вот так:
GET /books?limit=10&category=romance
6. PATCH вместо PUT
Маловероятно, что необходимо будет сразу полностью обновить всю запись, обычно есть конфиденциальные или полные записи, которые следует уберечь от манипуляций пользователя. Именно поэтому для выполнения частичных обновлений ресурса следует использовать PATCH, а вот PUT полностью меняет существующий ресурс. Они оба должны использовать тело запроса для передачи информации, подлежащей модификации. Разница лишь в том, что для PATCH это поля, а для запроса PUT – полный объект. Тем не менее, стоит отметить, что ничто не мешает нам использовать PUT для частичной модификации, нет никаких «ограничений на передачу по сети», которые бы это подтверждали. Это просто факт, которого стоит придерживаться.
7. Предоставьте более подробные ответы
Шаблоны доступа являются ключевыми при создании доступных ресурсов API и возвращаемых данных. Когда система растет, то и свойства записи также растут, но не всегда все эти свойства нужны клиентам для работы. Именно в таких ситуациях становится полезным предоставление возможности возвращать сокращенные или полные ответы для одной и той же конечной точки. Если пользователю нужны только некоторые поля, то упрощенный ответ помогает снизить расход трафика и потенциально сложность получения других вычисляемых полей.
Простой способ реализовать – предоставить дополнительный параметр запроса, чтобы включить или отключить предоставление более подробного ответа.
GET /books/:id
{
"bookId": 1,
"name": "The Republic"
}GET /books/:id?extended=true
{
"bookId": 1,
"name": "The Republic"
"tags": ["philosophy", "history", "Greece"],
"author": {
"id": 1,
"name": "Plato"
}
}
8. Обязанность конечной точки
Принцип единственной обязанности фокусируется на концепции удержания функции, метода или класса на одной обязанности, которую они выполняют хорошо. Мы можем сказать, что это наш API - хороший API, если он выполняет одну конкретную вещь и никогда не меняется. Это помогает пользователям лучше понять наш API и сделать его более предсказуемым, что облегчит общую интеграцию. Лучше всего расширить список доступных конечных точек, а не создавать очень сложные конечные точки, которые пытаются решить множество задач одновременно.
9. Предоставьте полную документацию по API
Пользователи вашего API должны понимать, как использовать доступные конечные точки и чего ожидать. Это возможно только при наличии хорошей и подробной документации. Обратите внимание на следующие аспекты, чтобы ваша документация была полной.
Доступные конечные точки с описанием их назначения
Права доступа, необходимые для выполнения конечной точки
Примеры вызовов и ответов
Сообщения о предполагаемых ошибках
Немаловажным является постоянное обновление документации после внесения изменений и дополнений в систему. Лучший способ для этого – сделать документацию по API неотъемлемой частью разработки. Двумя хорошо известными инструментами в данном вопросе являются Swagger и Postman – они доступны для большинства сред разработки API.
10. Используйте SSL для обеспечения безопасности и настройте CORS
Безопасность – еще одно очень важной свойство, которым должен обладать наш API. Настройка SSL путем установки действительного сертификата на сервер обеспечит безопасную связь с пользователями и предотвратит некоторые виды потенциальных атак.
CORS (Cross-origin resource sharing – Обмен ресурсами с запросом происхождения) – это функция безопасности браузера, которая ограничивает HTTP-запросы из различных источников, которые инициируются сценариями, запущенными в браузере. Если ресурсы вашего REST API получают непростые HTTP-запросы из разных источников, то вам нужно включить поддержку CORS для того, чтобы пользователи работали соответствующим образом.
Протокол CORS требует, чтобы браузер отправил предварительный запрос на сервер и дождался утверждения (или запрос учетных данных) с сервера перед отправкой фактического запроса. Запрос предварительной проверки отображается в API как HTTP-запрос, использующий метод OPTIONS (среди других заголовков). Значит, для поддержки CORS в ресурсе REST API необходимо реализовать метод OPTIONS, который будет отвечать на предварительный запрос, по крайней мере, со следующими заголовками ответа, предусмотренными стандартом Fetch:
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Allow-Origin
Какие значения назначать этим ключам, зависит от того, настолько открытым и гибким должен быть наш API. Мы можем назначить определённые методы и известные источники или использовать специальные символы, чтобы иметь открытые ограничения CORS.
11. Управление версиями API
В процессе разработки конечные точки начинают меняться и перестраиваться. Но мы должны, насколько это возможно, избегать внезапного изменения конечных точек для пользователя. Рекомендуется рассматривать API как ресурс с обратной совместимость, в котором новые и обновленные конечные точки должны быть доступны, но не должны влиять на предыдущие стандарты.
Вот где управление версиями API приходит на помощь – когда клиенты должны иметь возможность выбирать, к какой версии подключаться. Есть несколько способов описать управление версиями API:
Добавление нового заголовка x-version=v2
Наличие параметра запроса ?apiVersion=2
Версия как часть URL: /v2/books/:id
12. Кэшируйте данные для повышения производительности
Чтобы повысить производительность нашего API, полезно следить за данными, которые редко меняются и к которым часто обращаются. Для таких данных мы можем рассмотреть возможность использования базы данных в памяти или кэш-памяти, которая избавит от доступа к основной базе данных. Главная проблема здесь заключается в том, что данные могут устареть, поэтому следует решить вопрос с внедрением последней версии.
Использование кэшированных данных будет полезным для пользователей для загрузки конфигураций и каталогов информации, которые не предназначены для постоянного изменения в течение долгого времени. При использовании кэширования не забудьте включить Cache-Control в заголовки. Это поможет пользователям эффективно использовать систему кэширования.
13. Используйте даты в формате UTC
Сложно представить системы, которые в какой-то момент перестает работать из-за дат. На уровне данных важно быть логичным в том, как даты отображаются на клиентских приложениях. ISO 8601 – это международный стандартный формат данных для даты и времени. Данные должны быть в формате Z или UTC, для которых пользователи могут могли бы выбрать часовой пояс в случае, если такая дата должны отображаться при любых условиях. Вот пример того, как должны выглядеть даты:
{
"createdAt": "2022-03-08T19:15:08Z"
}
14. Конечная точка проверки работоспособности
Может произойти ситуация, когда наш API перестанет работать, и для его запуска потребуется время. При таких обстоятельствах клиенты хотят знать, что службы недоступны, и быть в курсе ситуации. Для этого предоставьте конечную точку (например, GET /health), которая бы определяла работоспособность API. Эта конечная точка может вызываться и другими приложениями, такими как балансировщики нагрузки. Можно продвинуться еще дальне и сообщать о периодах технического обслуживания или работоспособности частей API.
15. Разрешите аутентификацию по ключу API
Аутентификация с помощью ключей API даст возможность сторонним приложениям легко создавать интеграцию с нашим API. Эти ключи API следует передавать с помощью пользовательского заголовка HTTP (например, Api-Key или X-Api-Key). Ключи должны иметь дату окончания срока действия, и должна быть возможность их отозвать с целью признания недействительными по соображениям безопасности.
Разработка и тестирование (QA). Это безусловно крутое и востребованное направление, а спецов по ним на рынке разбирают как горячие пирожки.
Но есть аспекты . без которых вся история с мобильными приложениями, сервисами в интернете, размещенными в облаках и продаваемая по модели SaaS/PaaS или любое другая программная сущность, к которой так или иначе подключаются удаленные пользователи - не заработает.
Поговорим про роль человека, который разбирается в принципах построения сетей, коммутации, маршрутизации данных, о серверных инженерах, спецам по контактным центрам и так далее.
Эти ребята не пишут код в IDE и не имеют тимлида. Но именно от их работы зависит то, будет ли "хрипеть" разговор в трубке телефона в компании, как быстро будут передаваться чувствительные к задержкам данные, и именно они спасут сеть на 10 000 человек от петли маршрутизации и широковещательного шторма. Цена ошибки таких людей - высока, от этого и ценность шарящего сетевика также высокая.
В статье я расскажу об этом направлении, как в него попасть, сколько получают "сетевики", и за кем будущее в этой отрасли.
МТУСИ
Итак, свою историю я начну с прекрасного университета - МТУСИ (Московский технический университет связи и информатики). И именно этот университет посчастливилось закончить мне и большой части нашей команды.
Вообще, как написано в википедии
"Московский технический университет связи и информатики - российский отраслевой университет в области информационных технологий, телекоммуникаций, информационной безопасности и радиотехники."
Теоретически, да и практически, львиную долю кадров будущих инженеров связи готовят именно тут. В какой компании не бывал, с кем не общался, будь то провайдер, банк или интегратор - мтусишники везде. Занимаются сетями передачи данных, телефонией, архитектурой систем передачи или информационной безопасностью.
Университет - прекрасный. Преподавательский состав - прекрасный. Но материал, которому нас учили на 5 курсе университета в 2015 году был о том, как работает декадно шаговая АТС. Чтобы вы понимали, декадно шаговые АТС появились в СССР сразу после второй мировой войны. Забавно, но это была в прямом смысле громкая станция - там щетки скользили по специальным ламелям и издавали звуки. И вот спустя 70 лет, выпускаясь из университета, мы изучаем декадно - шаговый искатель. Кстати, вот он:
Тогда как телефонные системы, которые на тот момент существовали в энтерпрайзе, с которыми нам реально предстояло работать выглядели вот так:
В формате гибких программных приложений, в которых работают цифровые стандарты на базе IP протокола. Они имеют графический интерфейс на английском языке, а также программную консоль для более хардового управления, если хочется действительно залезть под капот.
Само собой, проблема известная и касается не только университета связи. Вы смотрели интервью Юрия Дудя с экономистом Сергеем Гуриевым?
Вы наверное помните, что там Дудь приводит цитату Гуриева, что он как - то сказал, что, "Российских студентов учат непонятно чему". На что Гуриев сказал, что рынок труда и российская система образования не связана, что плохо.
И это правда. Выходя из стен университета, ты имеешь отличный разговорный навык, но не актуальный знания, которые ждет от тебя работодатель и рынок.
Тут мы получили вывод №1:
Курсы Cisco CCNA
Я стал осознавать это примерно в конце второго курса, когда немного поработал в технической поддержке одного из интернет - провайдеров, который оказывал услуги для юридических лиц - это были каналы связи, услуги виртуальных частных сетей (VPN), телефонные номера.
Это был клевый опыт, а особенно, я помню одного из ведущих инженеров - это был дядька, который также закончил МТУСИ. На 70 - 75% он состоял из русского мата, но привыкнув, из его поучительных речей, когда он заходил к нам в поддержку, я понял главное - знания, полученные уже, и те, которые предстоит получить в ближайшие 3 года обучения - мне не пригодятся. Кстати, здесь хорошо подходит старый мем (они даже немного похожи):
Уже на стартовой позиции сотрудника технической поддержки меня окружали вендорные решения, то есть решения конкретных производителей: мультиплексоры Eltex, биллинговые системы, SFP модули, коммутаторы доступа, софт свичи, вендор Cisco.
И тут к нам плавно пришло осознание:
Что чтобы попасть во флоу, в рынок и в тренды, нужно учиться работать решениями, которые есть на рынке - то есть с решениями конкретных производителей. Причем не просто уметь кнопки нажимать и давать команды в консоли - а знать теория и глубоко понимать логику их работы.
Вообще, учеба в МТУСИ проходит в двух зданиях - первые 2 года мы учились на октябрьском поле, а оставшееся время на Авиамоторной. Так вот, переехав на новую территорию к третьему году обучения, мы стали обращать внимание - в здании есть несколько учебных центров.
Там был вендор Alcatel и Cisco. Решение учиться решениям вендора было принято сразу, вопрос был лишь в том - куда пойти - тут включились ассоциации:
Алькатель ассоциировался с:
А Cisco с городом Сан - Франциско:
Через год обучения мы закончили курс Cisco CCNA (Cisco Certified Network Associate) по маршрутизации и коммутации - это наиболее распространённый сертификат из всей линейки сертификации Cisco. Еще через 2 месяца мы подтвердили свои знания и сдали экзамен на получение сертификата и к концу 3 курса уже смогли трудоустроиться на работу в системные интеграторы на полставки на базовые инженерные позиции.
На самом деле, как я говорил раньше, наши ассоциации при выборе учебного центра нас не подвели. В энтерпрайзе (корпоративных ИТ инфраструктурах) решения на базе Cisco встречаются часто. Да и сама циска один из самых крупных вендоров телеком отрасли, а годных специалистов в России, которые могли бы работать с линейкой продуктов не так много.
Тут мы получили вывод №2:
Подвиды
Поговорим про то, какие бывают ребята из отрасли обслуживания инфраструктур:
Инженер по обслуживанию корпоративных систем связи - он же VoIP инженер. Этот человек хорошо разбирается в IP - телефонии, протоколах, знает стеку стека протоколов TCP/IP - зарплата от 50к на старте
Инженер по обслуживанию инфраструктуры информационных систем - он же серверный инженер. Этот человек хорошо разбирается в серверной начинке, знает наизусть Linux Based и Windows системы, отличит первый рейд массив от пятого, знаком с Chef, Ansible и Puppet, и докером - зарплата от 65 - 70 тыр. на старте
Инженер по обслуживанию корпоративной сетевой инфраструктуры - он же сетевик. Разбудив его ночью, он расскажет вам все про модель OSI, знает, как работают коммутаторы и маршрутизаторы нескольких вендоров, а на обеде расскажет вам все о протоколах маршрутизации трафика - от 50к на старте
Это три основные направления в отрасли - безусловно их больше и всех перечислить не получится - обслуживание информационных систем (ПО, разный софт), филд инженер, который работает руками и монтирует железо, инженеры поддержки пользователей и так далее.
С сетевиками и в целом, с этой категорией ребят все хорошо и они в тренде. Есть и будут еще долго. Но предлагаю смотреть дальше.
DevOPS инженер
Будущее за кросс-функциональными ребятами, которые не "заточены" под один продукт, а имеют широкий кругозор и знания.
Именно тут появляется методология DevOps, которая является акронимом от development и operations - то есть от разработка и эксплуатация. Девопс инженер сочетает в себе множество знаний из смежных отраслей, которые особенно актуальны для компаний, занимающихся разработкой софта и управлением большим количество серверов.
Дело в том, что при разработке, могут возникать случаи, когда что-то не работает, или работает не так, как хотелось бы:
В таком случае разработчик говорит:
Сетевик говорит:
И понеслась. Вообще, системные администраторы или сетевые инженеры в одно время базово научились программировать, подарив миру такие продукты как Chef, Puppet или Ansible, которые служат для автоматизации работы серверов. Но так случилось не со всеми - кто то остаётся хардовым сетевым инженером, который на пальцах объяснит вам как работает протокол BGP, но совершенно не понимает в программировании.
Решив проблему понимания между разработчиком и инфраструктурщиком. Тем самым, при достижении уровня понимания между этими ролями, компании могут достичь таких метрик как:
Сокращение времени для выхода на рынок;
Снижение частоты отказов новых релизов;
Сокращение времени выполнения исправлений;
Уменьшение количества времени на восстановления (в случае сбоя новой версии или иного отключения текущей системы).
Итак, попробую сформулировать, по пунктам, что же должен уметь прекрасный DevOps инженер будущего:
Легко ориентируется в Windows и Linux based системах.
Знает инструменты для управления конфигурацией и автоматизации серверов Chef, Puppet, Ansible.
Умеет писать скрипты. Минимум - на пайтоне
Знает сетевые технологии на уровне Cisco CCNA
Этого достаточно, чтобы уже получать в среднем по РФ 100-200 тысяч рублей.
Что забавно: есть город, и это не Москва, где девопс получает получает 160-360 тысяч рублей в месяц.
Как думаете какой?
Правильный ответ - Питер. Именно там девопс оценивается больше всего. Связано ли это с климатом, подвернутыми штанами или очками с Толстой черной оправой - ответить сложно.
Итоги
Итак, мы поговорили о пути инженера по телекоммуникациями, сетевой инфраструктуре, системам связи и инфраструктуры информационных систем. Затронули наиболее быстрые пути развития, обсудили зарплаты на старте и поговорили о том, как стать прекрасным DevOps инженером будущего.
Мы поняли, что ни один вуз не сделает из вас готового к рынку спеца, а чтобы быть таковым - нужно уметь работать с решениями конкретных вендоров, а проще всего это сделать с помощью авторизованных учебных центров.
Задавайте вопросы в комментариях - помогу :)
Вот вы пользователь Linux машины. И вот вам захотелось запустить какую-нибудь команду только на определенное время, и вы задаете вопрос - как это сделать? А вот как - использовать команду timeout.
Как взять timeout - об использовании команды
Базовый синтаксис
Как и следовало ожидать, синтакс у команды экстремально прост: сама команда timeout - опции - длительность выполнения (можно даже с единицами измерения) - целевая команда
Единицы измерения для указания длительности:
s - секунды (стоит по умолчанию)
m - минуты
h - часы
d - дни
Если вы не укажете никакого параметра по длительности, команда не будет активирована.
Примеры команд:
timeout 5 ping 1.1.1.1 - пингуем 1.1.1.1 5 секунд
timeout 5m ping 1.1.1.1 - пингуем 1.1.1 5 минут
timeout 5.5h ping 1.1.1.1 - 5,5 часов пингуем 1.1.1
Если у вас есть необходимость, можно запустить команду с добавкой sudo (если для целевой команды требуются права суперпользователя):
sudo timeout 100 tcpdump -n -w dump.pcap
Сообщение с космосом или отправка определенного сигнала исполняемому процессу
Если вы не указали какой-то особый сигнал, по умолчанию передается SIGTERM (сигнал о том, что надо бы мягко терминировать процесс). Однако, если вы укажете ключ -s после команды timeout, вы можете указать любой другой допустимый сигнал. К примеру: sudo timeout -s SIGKILL ping 1.1.1.1 или sudo timeout -s 9 ping 1.1.1.1
Обе команды выше идентичны, и если вы хотите увидеть весь список сигналов, просто введите kill -l
Как убить процесс, если он завис
Как вы уже поняли, SIGTERM - это сигнал, который отправляется после истечения таймаута, но он легко может быть проигнорирован процессом, и тогда процесс не остановится. Для уверенности в смерти процесса, нужно использовать ключ -k и некое временное значение. Тогда после окончания таймаута будет отправляться сигнал SIGKILL, который процесс не сможет проигнорировать при всем желании. В примере ниже команда выполняется одну минуту, и, если в течение 10 секунд после окончания таймаута она не "умирает", отправляется сигнал SIGKILL и "добивает" процесс:
sudo timeout -k 10 1m ping 1.1.1.1
Сохраняем статус
Команда timeout всегда возвращает значение 124 после истечения указанного времени или возвращает статус "exit" управляемой команды (той, что вы вводите после команды timeout). Таким образом, вы можете использовать ключ --preserve-status:
timeout --preserve-status 10 ping 1.1.1.1
Запуск команды явно, а не за кулисами
По умолчанию, timout работает в бэкграунде, и если вы хотите обратного (вдруг после запуска управляемой команды потребуется какой-нибудь пользовательский ввод), нужно использовать ключ -foreground:
timeout --foreground 10m ./bestscripteva.sh
Заключение
В 99% процентов случаев команда timeout требует всего двух аргументов и ни одного факта: времени исполнения и самой исполняемой команды. Однако, вы теперь знаете и другие фишки использования этой замечательной команды.