[15:41] Hi, what is a good way to get global env vars available within upstart processes? [18:29] I'm having a problem writing this upstart script. [18:30] Basically, on startup I need to run an external program to dump out some env. var settings into a tempfile, then I need to source that tempfile, then I need to exec the daemon. [18:31] But upstart ends up tracking the wrong PID. I think the PID it ends up tracking is the PID of that env-producing program, but maybe it's tracking the PID of mktemp. Not sure. [18:33] If there were some way to store environment variables set in the pre-start script so that the "script" section started with the same environment that pre-start had when it exited... [18:33] Of course, in the pre-upstart world this wasn't an issue, since the daemon writes its PID to a file in a known location, but in upstart... [19:02] Is there some way to forcibly tell upstart "You know nothing about this job; it's stopped."? [19:43] Hey, all! I am trying to check the status of cron service using sudo service cron status as a non-privileged user on ubuntu 14.04 desktop 64-bit but get a status: Unknown job: cron error in return. However, if I do the same thing on ubuntu 12.04 64-bit desktop I get the appropriate result. I notice that I can check teh status if I am root on 14.04. Why is this happening and how can I solve this? [19:54] Hey, all! I am trying to check the status of cron service using sudo service cron status as a non-privileged user on ubuntu 14.04 desktop 64-bit but get a status: Unknown job: cron error in return. However, if I do the same thing on ubuntu 12.04 64-bit desktop I get the appropriate result. I notice that I can check teh status if I am root on 14.04. Why is this happening and how can I solve this? [20:38] fizbin: pre-start script [20:38] fizbin: .... do stuff [20:38] fizbin: end script [20:38] fizbin: script [20:38] fizbin: source tmp-file [20:39] fizbin: daemond [20:39] fizbin: end script [20:44] xnox: So I have to use a constant temp file name? [20:44] I assume I delete in the post-start script? [20:45] fizbin: exporting environment in pre-start, will not be presered to daemon. [20:45] fizbin: alternative is to have two jobs -> first one "daemon-starter" which does: [20:45] task [20:45] .... do things to determine variables [20:46] start daemond FOO=BAR BAZ=TRATA [20:46] end script [20:46] (forgot 'script' just after task) [20:46] fizbin: the daemond job would then just be "exec daemond" [20:47] fizbin: but it will get the right environment because daemon-starter launches it. Hence daemond job shouldn't have any starton conditions. [20:47] fizbin: also please see cookbook about managing environment. [20:47] fizbin: what sort of things are you executing and sourcing inside the environment? [20:47] fizbin: typically it's akward when daemon rely on environment variables. [20:57] xnox: It's part of a vendor's system, and the system is intended to be deployed on an EC2 system, and it was doing a curl of http://169.254.169.254/latest/user-data [20:58] Which is a special URL on EC2 machines, and after that's dumped to a temp file it sources that file. [20:58] fizbin: why use an upstart job? does vendor provide an init.d script that you can install and use? [20:59] fizbin: this sounds very dubious, especially doing it over http. [20:59] Vendor instructions actually modify several different /etc/default/* files. Those are sourced by standard upstart scripts. [21:03] fizbin: i'm not sure i can at all help you. can you provide those instructions or actually show what's it's doing? i would separate things out: 1) curl > somewhere; start my-daemon ENVFILE=path-to-tmp-filename.a1231fab 2) my-daemon job bail if ENVFILE is empty, e.g. pre-start [ -n "$ENVFILE" ] || {stop; exit 1;} [21:03] and script [21:03] source $ENVFILE [21:03] end script [21:03] fizbin: so there is plenty of things you can do. Did you read cookbook? [21:03] xnox: Not if you're actually on an EC2 box. That IP is routed specially by Amazon's virtualization system. Intercepting anything to/from that specific IP would require a deep compromise of Amazon's systems, [21:04] fizbin: http://upstart.ubuntu.com/cookbook/ [21:04] xnox: I tried to read the cookbook, but figuring out just what the "expect" clause was talking about was seriously confusing. [21:05] fizbin: it tracks the first exec. [21:05] Upstart, at the moment, appears to me to be a much, much more brittle system than the old sysv init system. [21:06] fizbin: upstart jobs meant to execute a daemon that either runs in foreground, forks ones, or double forks. [21:06] In particular, on an upstart system you need to be extremely careful that none of your /etc/default files result in any other process running. [21:07] fizbin: if you have a script stanza that executes a lot of command, then that's not a daemon but a series of things -> put all of them into a script and have an upstart job that execs that. [21:07] So, for example, you can't comment out a chunk of some /etc/default file by preceding it with "if /bin/false; then" and then having a "fi" at the end of the commented region. [21:07] xnox: s/a lot of command/any program other than just the daemon/ [21:07] fizbin: by default we don't want to source anything from /etc/default and those things that do are for legacy compatibility instead. [21:08] fizbin: you should use /etc/init/job.override file instead where you can override any portion of the job (e.g. remove the sourcing of the /etc/default/* file) [21:08] fizbin: clearly the vendor system you are working with is not integrated / have upstart jobs written for. [21:09] fizbin: so why can you not use init.d script for it, which would be used on ubuntu? [21:09] fizbin: what vendor / software is this? [21:09] xnox: Ah. Well, despite what you may wish to do, upstart as I interact with it is upstart as Ubuntu ships it, which has nearly every upstart job source the relevant /etc/default file before exec'ing the daemon. [21:10] And it isn't the vendor's software directly that won't play nice with upstart - their instructions included modifying stuff like /etc/default/rsyslog which then made upstart lose track of rsyslogd. [21:11] here is example of correctly sourcing default that doesn't loose track of things [21:11] expect fork [21:11] respawn [21:11] pre-start script [21:11] modprobe -q autofs4 || true [21:11] end script [21:11] script [21:11] if [ -f /etc/default/autofs ] ; then [21:11] . /etc/default/autofs [21:11] fi [21:11] exec /usr/sbin/automount $OPTIONS [21:11] end script [21:12] fizbin: i'd want to here which vendor is this that advises people to break their rsyslog. [21:12] Sure, it doesn't.... until you put something in /etc/default/autofs that execs a different program. [21:13] fizbin: and looking at /etc/default/rsyslog -> the interface that file provides can be achieved with "echo exec rsyslogd -my -options > /etc/init/rsyslogd.override" [21:13] Put a curl command in /etc/default/autofs, or a cat, or ... I guess not an echo, because that's a shell builtin, but how about even a call to /bin/true [21:14] And then upstart loses autofs [21:15] Okay, so the result of my question of "how to make this work" is "don't actually do anything in /etc/default/whatever, because upstart can't handle it". [21:16] I will report this back to the vendor (FP Complete, their self-hosted pro version of the IDE. Admittedly, we also got a preview release, so they may have corrected it already before they went general availability) [21:29] At the very least, it would be nice if something in the cookbook said in big bold letters "If you run any program in your script except the daemon, upstart will get confused and be unable to find the daemon process. In particular, if you source external files (for example, files in /etc/default), those files must not do anything but set environment variables and invoke shell builtins." [21:36] It is kind of broken that upstart means attempting to comment a chunk out of what had always been a shell script (/etc/default files) with a "if /bin/false; then ... fi" wrapper introduces a whole new bug. [21:39] fizbin: in shell comments start with "#" ;-)