res2001

Вместо call используйте start

Возможно убит разъем. В этом случае может помочь правильное подключение передней панели. Это не сложно и бесплатно, так что начните с этого. Скачайте мануал на материнку у производителя, там написано как правильно подключить переднюю панель.
Купить новую - всегда успеете.

В цикле надо устанавливать флаг четности/нечетности, а сам вывод делать после цикла в зависимости от установленного флага. При этом можно проверять только на не четность. Например значение флага по умолчанию 1 (т.е. все числа четные), если хоть одно число не четное, то присваиваем флагу 0 и завершаем цикл (break), после цикла анализируем флаг и выводим YES или NO в зависимости от его значения.

Обычно подобные вещи делаются не так.
Для этого в cmake предусмотрена функция configure_file
Смысл в том, что вы создаете шаблонный файл, содержащий ссылки на переменные cmake. configure_file обрабатывает этот шаблон, заменяет все ссылки значениями переменных и создает из них новый файл. Этот новый файл вы и используете в проекте. Т.е. реального файла (в вашем случае conf.h) в проекте не существует, он появляется только во время компиляции.
Изменять значения переменных cmake пользователь может через параметры командной строки cmake с помощью ключа -D, например: cmake ... -DMY_VAL="New value".
Подобную переменную внутри cmakelists.txt обычно декларируют через option, там же можно указать и описание переменной и значение по умолчанию.
Примеры использования можете найти в любом более менее крупном проекте cmake на github.

Вы указываете имя файла без пути, значит ОС ищет файл в текущем рабочем каталоге. Когда вы запускаете скрипт в консоли, вы вероятно как раз находитесь в этом каталоге и у вас все работает. Когда запускает скрипт cron текущим каталогом является ... какой-то каталог, удобный крону по каким-то его кроновым причинам.
Так что правильный выход - указывать полный путь к файлу - просто передавайте полный путь к файлу в параметре запуска скрипта и

твои волосы будут мягкими и шелковистыми

.

softether это умеет.

Вроде ждет.
Но если служба не завершается по какой-либо причине, то не знаю какое поведение. Возможно отваливается по таймауту с каким-нибудь сообщением. Перенаправьте вывод stdout и stderr в файл, чтоб можно было проанализировать позже.
Вообще есть более продвинутая команда для работы со службами: sc /?
Можно остановить службу, проверить состояние и если остановлена, то запустить.

Вы не правильно инициализируете указатель ptr: int *ptr = s[0];
Обращение s[0] просто возвращает первый элемент массива (в вашем случае 1). Это не указатель.
Правильная запись была бы:

int *ptr = &s[0];
или
int *ptr = s;

Если бы вы поставили максимальный уровень сообщений компилятора, то в этом месте он бы вам ругнулся.
В целом рекомендую в своих проектах всегда выставлять максимальный уровень сообщений и исправлять ошибки, на которые указывает компилятор. В большинстве случаев компилятор выдает абсолютно правильные рекомендации. Конечно бывают и исключения.

Атомарные переменные - это такие же переменные как и остальные. Инициализировать их вы можете сколько угодно раз. Это относится только к встроенным типам. Атомарные классы - это сказка.
Но на них накладываются некоторые ограничения:
1. выравнивание переменной - переменная должна находится по адресу обычно кратному размеру переменной. Если не будет правильного выравнивания, то intelовские процы могут сделать 2 операции чтения, что уже не будет атомарной операцией. Другие процы могут сгенерировать какое-нибудь исключение.
2. атомарная переменная всегда volatile - т.е. компилятор не может ее кэшировать в регистре, всегда идет обращение к памяти.
Не все атомарные переменные в std действительно атомарны. Это проверяется с помощью atomic_is_lock_free(). Атомарность зависит от платформы. Например на x86 int64 - не атомарна из-за ограничений процессора. Тогда как на 32 битных АРМах она вполне атомарна.
При обычном чтении/записи атомарных переменных (с упорядочиванием памяти memory_order_seq_cst) происходит синхронизация кэшей ядер - из-за чего атомарные операции "дороже" не атомарных. Но этот процесс на разных архитектурах стоит по разному. Для синхронизации кэшей есть отдельные ассемблерные инструкции.

В целом все undefined behavior для атомарных переменных в std связаны с:
1. возможностью объявить атомарным любой класс
2. не для всех встроенных типов на конкретной платформе гарантируется реальная атомарность (atomic_is_lock_free).
3. если вы не будете соблюдать ограничения, то же ничего гарантировать нельзя.
Так что особо пугаться undefined behavior не стоит. Просто соблюдайте ограничения, не используйте атомарные классы и удостоверьтесь, что встроенные типы на вашей платформе действительно атомарны.