rsyslogd как руководитель сеанса
Perl
Однострочник Python:
$ python -c "import sys; print ','.join([repr(l.strip()) for l in sys.stdin])" < input.txt
'd3heatmap','data.table','ggplot2','htmltools','htmlwidgets','metricsgraphics','networkD3','plotly','reshape2','scales','stringr'
Работает очень просто - мы перенаправляем input.txt в stdin, используя < ], считайте каждую строку в список с помощью .strip () , удаляющего символы новой строки
, и repr () , создавая цитируемое представление каждой строки. Затем список объединяется в одну большую строку с помощью функции .join () с , в качестве разделителя
В качестве альтернативы мы могли бы использовать + для объединения кавычек в каждая зачищенная линия.
python -c "import sys;sq='\'';print ','.join([sq+l.strip()+sq for l in sys.stdin])" < input.txt
Perl
По сути та же идея, что и раньше: прочитать все строки, удалить завершающую новую строку, заключить в одинарные кавычки, поместить все в массив @cvs и распечатать значения массива, соединенные запятыми.
$ perl -ne 'chomp; $sq = "\047" ; push @cvs,"$sq$_$sq";END{ print join(",",@cvs) }' input.txt
'd3heatmap', 'данные.table ',' ggplot2 ',' htmltools ',' htmlwidgets ',' metricsgraphics ',' networkD3 ',' plotly ',' reshape2 ',' scale ',' stringr '
Править
Я действительно взглянул на старую систему ubuntu 10.04, в которой был запущен rsyslogd 4.2.0.
Этот не вызвал setsid () вообще (поэтому унаследовал sid от процесса, выполняющего его), а вместо этого сделал (здесь из вывода strace ):
19391 open("/dev/tty", O_RDWR|O_LARGEFILE|O_CLOEXEC) = 0
19391 ioctl(0, TIOCNOTTY) = 0
Чтобы отсоединить от терминала.
Глядя на исходный код , он делает это только тогда, когда HAVE_SETSID не установлен. Очевидно, что в Linux есть setsid () , и он существует уже несколько десятилетий, так что здесь что-то не так.
Теперь, посмотрев на исходный код, просто процедура сборки никогда не устанавливает HAVE_SETSID , поскольку не проверяет поддержку setsid () в первую очередь.
Ошибка (опечатка: setsid пишется setid в файле autoconf) была исправлена в 2013 г. (впервые выпущена в rsyslogd 7.5.3).
(кстати, см. Раздел TODO о HP / UX в старом коде, который показывает, что авторы уже поняли, что что-то не так (но не исследовали это намного позже)) .
Сохраняем исходный ответ ниже, так как информация там может оказаться полезной.
Необычная догадка:
Если вы являетесь лидером сеанса и открываете устройство tty без флага O_NOCTTY , то вы становитесь процессом управления терминала.
Вот почему при попытке запустить приложение (которое в противном случае не было разработано для работы в качестве демона), чтобы оно работало как демон, рекомендуется выполнить еще одну вилку после setsid () перед выполнением чтобы убедиться, что процесс случайно не станет контроллером терминала, если по какой-то причине он откроет tty-устройство.
syslogd обычно открывает tty-устройства для отправки пользовательских сообщений, поэтому, возможно, в вашей книге говорится, что syslogd не является лидером сеанса, описывая поведение реализаций syslogd со времен, когда флаг O_NOCTTY не существовал ( хотя этот флаг существует как минимум с конца 80-х).
Другой подход заключается в том, что syslogd должен убедиться, что все файлы, которые он открывает, открываются с помощью O_NOCTTY, что, вероятно, является тем, что делает ваш rsyslogd (ничего общего с systemd ).