Lançar o daemon na inicialização como um usuário específico no Mac OS X (Server) Mavericks

1

Eu quero iniciar um servidor de IC (TeamCity 8.1) na inicialização de um Mac OS X Server que executa o Mavericks. Não quero que o servidor de IC seja iniciado pelo usuário raiz, mas por outro usuário no sistema.
O usuário com o qual quero iniciar o servidor é server1: staff. Eu instalei o TeamCity em / Applications / TeamCity. A pasta TeamCity é de propriedade de server1: staff.
Em seguida, criei 2 plists em / Library / LaunchDaemons de propriedade de root: wheel, mas especificando que deseja que esse processo seja iniciado pelo server1: staff user.

Aqui estão as plists. Este começa o servidor:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>WorkingDirectory</key>
    <string>/Applications/TeamCity</string>
    <key>Debug</key>
    <false/>
    <key>Label</key>
    <string>jetbrains.teamcity.server</string>
    <key>OnDemand</key>
    <false/>
    <key>KeepAlive</key>
    <true/>
    <key>ProgramArguments</key>
    <array>
        <string>bin/teamcity-server.sh</string>
        <string>run</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>StandardErrorPath</key>
    <string>logs/launchd.err.log</string>
    <key>StandardOutPath</key>
    <string>logs/launchd.out.log</string>
    <key>UserName</key>
    <string>server1</string>
</dict>
</plist>

Este começa o agente de compilação que executa as compilações:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Debug</key>
    <false/>
    <key>KeepAlive</key>
    <true/>
    <key>Label</key>
    <string>jetbrains.teamcity.BuildAgent</string>
    <key>OnDemand</key>
    <false/>
    <key>ProgramArguments</key>
    <array>
        <string>launcher/bin/TeamCityAgentService-macosx-universal-32</string>
        <string>-c</string>
        <string>../conf/wrapper.conf</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>SessionCreate</key>
    <true/>
    <key>StandardErrorPath</key>
    <string>logs/launchd.err.log</string>
    <key>StandardOutPath</key>
    <string>logs/launchd.out.log</string>
    <key>WorkingDirectory</key>
    <string>/Applications/TeamCity/buildAgent</string>
    <key>UserName</key>
    <string>server1</string>
</dict>
</plist>

Com esta configuração, o servidor não inicia na inicialização.
A única maneira de ter o servidor iniciado na inicialização com minha configuração é sem especificar o UserName / UserGroup no plist. Mas com isso o servidor é iniciado com o usuário root. Eu já tentei mudar a propriedade do plist para coincidir com o servidor1: usuário da equipe, mas sem sucesso.
Estou meio preso a essa configuração e não sei o que há de errado com ela.
Qualquer dica é bem vinda.

[EDITAR]
Não tenho nada errado no Console.app sobre TeamCity.
Para ter certeza de que reinstalei o TeamCity do zero etc.
Não há nada em launchd.err.log. Embora eu achei isso em launchd.out.log, mas eu não sei quando isso aconteceu (atualmente reiniciando após a exclusão de todos os arquivos de log)

BuildId=null, AgentOwnAddress='null', AlternativeAddresses=[10.175.11.48, 192.168.2.92], Port=9090, Version='29939', PluginsVersion='29939-md5-51785f46b7e643a588892acce02b9333', AvailableRunners=[Ant, Duplicator, gradle-runner, Inspection, Ipr, JPS, Maven2, rake-runner, simpleRunner, Xcode], AvailableVcs=[perforce, mercurial, jetbrains.git, svn, cvs], AuthorizationToken='afccc2fae65d1c580e34d4aed4cc55df', PingCode='DX5fzIvbgFCvVghhwuvARdEU33XOfzCW'} 
jvm 1    | Call http://localhost:8111/RPC2 buildServer.registerAgent3: java.net.ConnectException: Connection refused 
jvm 1    | Registering on server http://localhost:8111, AgentDetails{Name='Default Agent', AgentId=null, BuildId=null, AgentOwnAddress='null', AlternativeAddresses=[10.175.11.48, 192.168.2.92], Port=9090, Version='29939', PluginsVersion='29939-md5-51785f46b7e643a588892acce02b9333', AvailableRunners=[Ant, Duplicator, gradle-runner, Inspection, Ipr, JPS, Maven2, rake-runner, simpleRunner, Xcode], AvailableVcs=[perforce, mercurial, jetbrains.git, svn, cvs], AuthorizationToken='afccc2fae65d1c580e34d4aed4cc55df', PingCode='DX5fzIvbgFCvVghhwuvARdEU33XOfzCW'} 
jvm 1    | Call http://localhost:8111/RPC2 buildServer.registerAgent3: java.net.ConnectException: Connection refused 
wrapper  | TERM trapped.  Shutting down.
jvm 1    | Processing shutdown hook. 
jvm 1    | Sending agent force shutdown command to: http://localhost:9090 
jvm 1    | Shutdown command successfully sent. Agent is exiting. 
jvm 1    | Stop command called 
jvm 1    | Agent process finished 
jvm 1    | Agent has exited with code: 30 
jvm 1    | Launcher is exiting 
wrapper  | <-- Wrapper Stopped  

[EDIT2] Depois de reiniciar Eu não tenho nada nos logs do servidor e Console.app (o servidor não inicia, então acho que é um comportamento esperado).

    
por florian 18.03.2014 / 14:40

1 resposta

1

O uso de todos esses caminhos relativos é um pouco superficial. Eu acho que você não está pensando em seu diretório de trabalho atual e caminhos relativos corretamente.

Por exemplo, o comando build listplist especifica que seu diretório de trabalho é…

/Applications/TeamCity/buildAgent

… mas um dos argumentos do programa que você passa para o binário do lançador é…

../conf/wrapper.conf .

Tenho certeza de que isso seria interpretado como relativo ao diretório de trabalho de…

/Applications/TeamCity/buildAgent

… não é o diretório do binário…

/Applications/TeamCity/buildAgent/launcher/bin .

Então você está realmente dizendo para procurar no principal…

/Applications/TeamCity/conf

… que normalmente não tem wrapper.conf , mas acho que você pensou que estava dizendo para procurar…

/Applications/TeamCity/buildAgent/launcher/conf

… que é onde normalmente vive wrapper.conf .

Eu acho que você pode ter algum outro diretório de trabalho / erros de caminho relativos em seus plists também. Por exemplo, parece que você tem dois diretórios logs separados, então você tem dois conjuntos separados de arquivos stdout / stderr launchd. Compre talvez seja o que você queria.

Acho que você provavelmente deveria corrigir esses problemas de caminho primeiro. Este pode ser todo o seu problema, não um problema de lançamento. Mas, mesmo que não seja, você precisa esclarecer isso para não atrapalhar a solução de problemas adicionais do launchd.

    
por 18.03.2014 / 18:49