Bug 29493 - Краш при запуске
: Краш при запуске
Status: NEW
: Branch p7
(All bugs in Branch p7/puppet-server)
: не указана
: all Linux
: P3 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2013-10-18 11:10 by
Modified: 2017-05-15 15:05 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2013-10-18 11:10:16
Здравствуйте!
Пытаюсь запустить puppetmasterd:
[root@linupd puppet]# service puppetmasterd restart
Service puppetmasterd is not running.                                          
                                                                               
                                           [PASSED]
Starting puppetmasterd service:                                                
                                                                               
                                           [ DONE ]
[root@linupd puppet]# service puppetmasterd status
puppetmasterd is dead, but stale PID file exists
[root@linupd puppet]# service puppetmasterd stop
Service puppetmasterd is not running.             


Смотрю /var/run/puppet/ - pid=11970

kill 11970
bash: kill: (11970) - Нет такого процесса

По идее puppet мёртв, но:
netstat -an | grep 8140

По факту он не стартует

Запускаю puppetmasterd --verbose
/usr/lib/ruby/rubygems/custom_require.rb:36:in `require': iconv will be
deprecated in the future, use String#encode instead.
/usr/lib/ruby/site_ruby/puppet/util/pidlock.rb:75:in `kill': Operation not
permitted (Errno::EPERM)
    from /usr/lib/ruby/site_ruby/puppet/util/pidlock.rb:75:in `clear_if_stale'
    from /usr/lib/ruby/site_ruby/puppet/util/pidlock.rb:11:in `locked?'
    from /usr/lib/ruby/site_ruby/puppet/util/pidlock.rb:33:in `lock'
    from /usr/lib/ruby/site_ruby/puppet/daemon.rb:46:in `block in
create_pidfile'
    from /usr/lib/ruby/site_ruby/puppet/util.rb:44:in `block in synchronize_on'
    from /usr/lib/ruby/sync.rb:227:in `sync_synchronize'
    from /usr/lib/ruby/site_ruby/puppet/util.rb:44:in `synchronize_on'
    from /usr/lib/ruby/site_ruby/puppet/daemon.rb:45:in `create_pidfile'
    from /usr/lib/ruby/site_ruby/puppet/daemon.rb:21:in `daemonize'
    from /usr/lib/ruby/site_ruby/puppet/application/master.rb:193:in `main'
    from /usr/lib/ruby/site_ruby/puppet/application/master.rb:146:in
`run_command'
    from /usr/lib/ruby/site_ruby/puppet/application.rb:309:in `block (2 levels)
in run'
    from /usr/lib/ruby/site_ruby/puppet/application.rb:416:in `hook'
    from /usr/lib/ruby/site_ruby/puppet/application.rb:309:in `block in run'
    from /usr/lib/ruby/site_ruby/puppet/application.rb:407:in `exit_on_fail'
    from /usr/lib/ruby/site_ruby/puppet/application.rb:309:in `run'
    from /usr/sbin/puppetmasterd:4:in `<main>'
------- Comment #1 From 2013-10-18 13:22:53 -------
Конфигурацию не правили? Я проверил при запуске на дефолтовой конфигурации на
p7 - всё работает.
------- Comment #2 From 2013-10-18 14:07:15 -------
(В ответ на комментарий №1)
> Конфигурацию не правили? Я проверил при запуске на дефолтовой конфигурации на
> p7 - всё работает.
Приветствую Skull!
Когда этот вопрос летом копали - там вроде всё было ок и я взял клиента и
клиент вроде отправил сертификат и сервер его подписал, однако, на клиенте всё
валится с указаниями на то, что нет доступа к шарам указанным в конфиге puppet.
Я перечитал на текущий момент все описания, что были и по настройке, вывод
puppet apply --configprint all порты, шары прописаны, на сколько я могу судить,
верно. При этом, nmap -sS IP с "доверенной" машины в сети - не кажет открытых
портов 8140 и 8139 - что, как мне кажется говорит об отсутствии данных сервисов
снаружи. В управлении брандмауэром прописаны эти порты.
На клиенте в свою очередь ругань (puppet -test) на недоступность плагинов,
недоступность фаловой шары ...
Если Вас не затруднит, не могли бы вы скинуть Ваш вариант конфигов и вывод в
configprint all. Я просто не понимаю где ещё смотреть. Единственное - это
поднять сервант с ноля и подсунуть заведомо рабочие конфиги ...