[20:42] Hi, looking for a good link to help trouble shoot an init script inside an LXD container [20:44] the service ( salt-master version 15.08 ) starts just fine directly, and other init scripts are working as expected. but salt-master always fails with 'job failed to start' . I can't figure out what is expected ( and not there ) by the init script. [20:45] I am reading the cookbook page... [20:47] First, enable logging of init script. That's "console log". Second, enable logging of your program, if it has one. [20:47] And third, pastebin your init script so far. Let's take a look. [20:49] k [20:51] http://pastebin.com/9d6er0RC [20:51] doing logging [20:51] Well, that' snot upstart script. [20:52] huh. I just assumed trusty was upstart [20:52] It is, but what you linked is an abomination. [20:52] lol, that's good to know [20:52] it's what came with the package [20:53] They are still living in the 2008… [20:53] wow [20:54] I was trying to figure out what might be missing from my container environment and not finding anything. but it sounds like what I really need is a new init script. [20:55] http://pastebin.com/v67FsCHt [20:55] That'a about all that you need. Likely. [20:55] If salt-master have a switch to run explicitly in foreground and not daemonize, use that. [20:56] it has -d (daemonize) and -l debug options [20:56] that's so simple. [20:56] Well, okay. Just leave -d out. Upstart does process control, so it needs to know what is running. [20:57] Yes, it is, in many cases. [20:58] thanks man [20:58] There's 3 types of daemons. 1. Very simple ones, no config at all. 2. Those required config in comandline. 3. Those with external config. [20:58] Upstart is good for 1 and 3, you just start daemon and it does everything it has to do. [20:58] this is 3 (in a default location) [20:58] #2, of course, needs some treatment more often than not :/ [20:59] And not always a trivial treatment, given you can't pass options from pre-start to start. [20:59] cool. I'm adding this to my deployment [21:02] Do note the script don't have any start or stop clauses. You'll have to figure these your yourself, once you have your daemon up and running. [21:02] sure, thanks [21:02] Also check the cookbot for "expect …" syntax, if upstart still losing the tail. [21:02] cookbook** [21:04] (Some services fork to drop privileges after initialization, no way around that, unless you start them with restricted privileges to begin with, which is not always possible, i.e. if they need ports in 0..1023 range.) [21:04] k. [21:05] salt-master is not starting with the simple init script either. so I think my container env is missing something that's not needed by all services [21:07] Look in logs. (add "console log" to the script, add -l debug or what not to the daemon parameters.) [21:07] Log is in /var/log/upstart/* [21:08] "console log" is an overall good idea, though. [21:09] there's no 'salt-master' file in /var/log/upstart. [21:09] the return is instantaneous [21:09] root@salt01:/etc/init.d# service salt-master start [21:09] start: Job failed to start [21:11] 1. Delete "salt-master" from /etc/init.d. [21:11] ok [21:11] 1. Run init-checkconf /etc/init/salt-master.conf [21:11] It will at least tell you if it is syntactically correct. [21:12] File /etc/init/salt-master.conf: syntax ok [21:12] initctl start salt-master [21:12] initctl: Job failed to start [21:13] What's in logs? [21:13] there's still no salt-master in /var/log/upstart [21:13] Anything in system log? [21:13] so far, syslog has only dhcp messages. [21:15] Try something real simple? Like exec /bin/printf "Started ok" [21:19] ok. this one fails with an instanc 'Job failed to start': http://pastebin.com/D3ZuaXrd [21:20] but this one works just fine: http://pastebin.com/k70KwXfh [21:21] permissions are identical [21:24] my paste is wrong, old one from klipper. I changed it to /usr/bin/printf [21:24] minor detail [21:32] Again, for the … time. [21:33] Do not confuse init script and upstart job. They are located in different places and started by different mechanics. [21:35] Also sorry, it is /usr/bin/printf [21:36] Just tried this script myself: http://pastebin.com/e4MFSCYM [21:36] # initctl start xxx [21:36] xxx start/running, process 19415 [21:39] ok yeah, that works [21:42] So, if you now replace /usr/bin/printf with /usr/bin/salt-master -l debug etc. it should at least try to start it. [21:44] using initctl and not service, salt-master started after I commented out #limit nofile 100000 100000 [21:45] and when I remove the abominable script I can start salt-master with 'service' [21:46] 100k ? :D [21:46] Even MySQL don't need that many. [21:46] Happily working with 32k [21:47] oh, actually it works when /etc/init.d/salt-master still exists. I guess it's not even relevant here. Hi upstart, nice to meet you. [21:48] As long as it is not installed… Or not called directly… You're using [21:48] upstart. [21:48] I suggested to get rid of it to reduce confusion. [21:48] at 50000 it works [21:49] thanks so much AnrDaemon [21:49] Does it actually do need that many open files? [21:50] in a much bigger environment , yes. but then I probably wouldn't be using a container [21:50] Fair point. [21:50] I'm actually trying to stand up a dev test env, so pretty small. just a dozen or so clients ( not thousands ) [21:51] the default lxd env probably sets a cap [21:51] ok, thanks for you help. thanks to you I can go have some family time :) [21:56] :D