[06:30] I'd like to do complex "start on" conditions and restarting is important to me, I think I saw someone say the issue could be worked around by using extra jobs, but I don't remember the specifics, can anyone point me in the right direction? [08:57] i've made the followin dansguardian upstart job but echo doesnt work despite using console output http://paste.ubuntu.com/834957/ could anyone give me some hints? [14:29] JanC: you suggested a couple of days ago that this was the right channel to ask feedback on upstart scripts? if you have the time, have a look at my previous message === marrusl_ is now known as marrusl [20:16] what are the most likely reasons to see runlevel "unknown" ? [20:16] SpamapS, ^ :) [20:16] from what I gather it's often a sys v service failing? [20:20] marrusl: if you're up to sysv.. you're at runlevel 2 already [20:21] doh [20:21] SpamapS, sooooo.... no. [20:21] What else? [20:22] I'm going to get a --verbose log regardless. [20:22] But it hasn't happened since we started looking! (of course) [20:51] bencer: i assume you're using upstart 1.4? [21:13] bradleyayers: i'm using precise [21:13] so, yes, 1.4 [21:13] everything works fine, but the output thing [21:15] does it work if you log to a file? [21:48] marrusl: unknown is schroedingers runlevel [21:50] SpamapS, lol. yea verily. [21:57] bradleyayers: as far as i could see no, should go to syslog, right? [21:57] or you mean echoing into a /tmp file? [21:58] well there's console options to output to a file aren't there? i meant try those [21:58] ok, going to give that a try [21:58] perhaps pre-start stuff doesn't adhere to the same console rules as exec/script [22:01] by default should be logging to syslog, right? [22:16] I'm not 100% certain but IIRC console log is still disabled in precise [22:16] you have to boot with '--log' [22:20] SpamapS: so, now way to echo anything into the console? [22:20] basically i'm trying to replicate init.d behaviour as close as possible: http://paste.ubuntu.com/834957/ [22:21] bencer: console output will go to /dev/console [22:21] bencer: and | logger will go to syslog [22:22] and what about echoing to the terminal? [22:22] thats not possible [22:22] ok, understood [22:22] its been discussed.. perhaps via a dbus channel to initctl [22:22] but first we wanted to be able to log somewhere reliably :) [22:22] what do you suggest i should do in this case? [22:23] /dev/console or syslog? [22:23] because i'm going to find this issue in other init.d scripts [22:23] bencer: for precise? [22:23] yes [22:23] bencer: --log will be on by default [22:23] so use console log [22:24] SpamapS: what i'm trying to do is to submit patches to migrate dansguardian, isc-dhcp, bind9 and slapd (at least) to upstart [22:24] bencer: slapd you have to be careful with.. [22:24] and i've 7 days left :) [22:24] bencer: its signals are non-standard [22:25] bencer: it may be better to still call the init.d script, from pre-start and post-stop scripts.. and just the upstart job to control when it starts/stops in the boot [22:25] what should i do in this case? [22:25] is it possible to start a process as another user, instead of as root using upstart? [22:25] actually i'm very interested in the respawn thing [22:25] not in the boot speed up [22:26] ianl`: http://upstart.ubuntu.com/cookbook/#changing-user [22:26] thanks [22:26] bencer: s/boot speed up/boot coordination/ [22:26] agreed, speed up is only a consecuence of that :) [22:26] bencer: having an upstart job has very little to do with speed up.. it allows you to coordinate the start of other things which need slapd [22:27] and is there any way to transform signals or something like that? or i'm basically against the wall here? [22:29] bencer: you can change the kill signal, but not the reload signal [22:31] SpamapS: so the problem is that slapd doesnt use sighup for reloading? [22:31] bencer: right, and I think TERM is also dangerous [22:31] bencer: RTFM on slapd before doing this. :) [22:31] i will [22:31] thanks for the feedback [22:32] well, i could imagine if nobody had done this before for popular packages like slapd, there was a reason [22:34] bencer: there are open bugs on many [22:35] well, for example on dansguardian seems to be trivial to do [22:35] bencer: frankly, I don't see enough value for some things. slapd actually does need to be done, because it can be used to support local auth [22:36] on my experience, for example, dansguardian is very useful, on zentyal dansguardian used to die from time to time, using the respawn thing, if it crashes, everybody is happy because it comes back to life itself [22:37] and this way, we dont have to install other things like runit or similar [22:39] I love the concept. But upstart's development hasn't really blossomed enough to support all the use cases that init.d scripts can. [22:42] what we used to do in zentyal to take advantage of the respawn thing was [22:43] pre-start script [22:43] /etc/init.d/slapd stop || true [22:43] end script [22:43] exec /usr/sbin/slapd -d 0 -h 'ldap://0.0.0.0/ ldapi://%2fvar%2frun%2fslapd%2fldapi/????x-mod=0777' -u openldap -g openldap -F /etc/ldap/slapd.d/ [22:43] respawn [22:43] but then, if we slapd gets updated, the postinst does invoke-rc.d slapd restart [22:43] and things can go funny [22:49] bencer: in newer versions of invoke-rc.d, restart is stop/start [22:49] bencer: it used to not reload the upstart file