[12:19] <flaf> Hi @all. In fact, this is not a bug of upstart above but a bug of "mountall" used by upstart to mount filesystems in fstab. I have made a bug report here: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1588594
[16:53] <frew> if I wanted to set an envvar for all services (as opposed to having to put env FOO=1 in each one) is there a way to do that?
[16:55] <chras> not without implementing it yourself in some form, like doing an environment file that you source, or passing or when you run initctl start $job KEY=VAL
[16:55] <frew> ok.
[16:55] <frew> oh well.
[16:55] <frew> would be nice
[16:56] <chras> but there isnt like a global default environment thing
[16:56] <frew> right.
[16:56] <chras> that aim aware of
[16:56] <AnrDaemon> frew: Can you tell us, why you want to do that?
[16:56] <frew> sure
[16:56] <frew> we want our services use /mnt/tmp instead of /tmp
[16:56] <frew> setting TMPDIR to that is sufficient
[16:56] <AnrDaemon> Fail.
[16:56] <frew> but doing that in every unit sucks
[16:56] <AnrDaemon> Mount /tmp where you want it, problem solved.
[16:57] <chras> well
[16:57] <frew> have you done this before AnrDaemon?
[16:57] <AnrDaemon> http://refspecs.linuxfoundation.org/fhs.shtml
[16:57] <frew> because some early boot stuff uses tmp
[16:57] <AnrDaemon> Nothing critical, to my knowledge.
[16:57] <frew> so you haven't done it then.
[16:58] <frew> "Fail."
[16:58] <frew> :P
[16:58] <AnrDaemon> And if it uses /tmp before / is mounted, well, what can i say?
[16:58] <chras> frew: is it your desire to have your TMPDIR be somewhere other then temp, for everything?
[16:58] <frew> chras: well, of course it gets worse
[16:58] <chras> like i would be cautious about doing that
[16:58] <frew> chras: I was wanting it to be somemthing some units would opt out of
[16:59] <chras> i think its a little safer / cleaner to just set your TMPDIR per application/service
[16:59] <frew> so like, ssh I'd manually set TMPDIR back to /tmp
[16:59] <frew> yeah
[16:59] <frew> for sure safer
[16:59] <AnrDaemon> Overcomplication. Maintenance headache.
[16:59] <frew> a non-trivial amount of things need tmp to be on the same partition as root
[16:59] <chras> like simply from the stance of creating unexpected behaviour
[16:59] <frew> so those would need it to be the regular /tmp
[16:59] <frew> chras: sure.
[17:00] <chras> one option you could do is
[17:00] <chras> you could have one event which spawns the other ones with initctl start ${otherjob} TMPDIR=${new_temp_dir}
[17:00] <chras> should work with emit too
[17:00] <frew> yeah I considered exactly that
[17:00] <AnrDaemon> frew: What I see from here is that you're solving problem with wrong tools. If you want isolation, get LXC or Docker, or what else suits your needs.
[17:00] <frew> sounds a little rube goldberg-y for this kind of thing
[17:00] <chras> iirc initctl emit start_all_my_junk TMPDIR=${tmpdir}
[17:00] <chras> should work 
[17:00] <frew> right
[17:00] <frew> yeah maybe
[17:00] <chras> adn then all your other things can just start on start_all_my_junk
[17:00] <frew> right.
[17:01] <frew> chras: thanks; I'll look into doing that
[17:01] <chras> personally, i just source /etc/event.functions to get my common functions/environment/etc
[17:01] <frew> that's a good idea.
[17:01] <frew> I should just make a thing all of our stuff uses
[17:01] <chras> and my source file also includes in /etc/event.functions.d/*
[17:01] <chras> so if you need to add in extra variables in a new package/service/whatever
[17:01] <AnrDaemon> Except sourcing anything is not an option. You can't set-env if a job runs with setuid.
[17:01] <chras> it can be added without modifying existing things
[17:02] <frew> AnrDaemon: ...what are you talking about?
[17:02] <chras> AnrDaemon: why not?
[17:03] <AnrDaemon> Why not what? Why it doesn't work? I don't know.
[17:03] <frew> ugh
[17:03] <AnrDaemon> + initctl set-env USER=php-fpm
[17:03] <AnrDaemon> initctl: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[17:03] <frew> AnrDaemon: he means source in the script.
[17:04] <AnrDaemon> Sourcing is not an option. You have to set these variables to the job to exec your service.
[17:04] <frew> whatever dude
[17:05] <AnrDaemon> Else upstart will not track the right PID, or get stuck if you try and use "expect fork/daemon".
[17:05] <frew> script\n. $to_source\nexec foo\nend script # <-- look; it works ma
[17:06] <chras> AnrDaemon: i only ever do stuff with foreground processes, so thats not a concern for me
[17:06] <frew> same.
[17:06] <frew> forking is for chumps
[17:06] <AnrDaemon> That' swhat I've tried to do last week.
[17:07] <AnrDaemon> Spawning per-user FCGI daemons without using master running as root.
[17:07] <chras> but yes, it would be nice if set-env worked for all of upstart, and not just user/session jobs
[17:08] <AnrDaemon> exec /usr/sbin/php5-fpm --fpm-config="/etc/user-fcgi/$USER.conf" --pid="/run/$USER/php-fpm.pid" $INIFILE -d open_basedir="$HOME" --nodaemonize
[17:08] <frew> chras: I think if I *really* wanted to make that work, I could tell the kernel to add en env var
[17:08] <frew> chras: but I'm not gonna reboot ;)
[17:08] <chras> right
[17:08] <AnrDaemon> And every variable I need to set in instance pre-start.
[17:08] <frew> though upstart might clear the env, which is reasonable
[17:08] <AnrDaemon> It does.
[17:09] <chras> variables set in pre-start wont appear in other contexes
[17:09] <chras> only in pre-stat
[17:09] <AnrDaemon> chras: man initctl | grep -A7 set-env
[17:09] <frew> AnrDaemon: if you want to get env vars, you have to use script like I was saying.
[17:09] <frew> (from a file)
[17:09] <chras> AnrDaemon: yes, if you read the docs it says specificly, that set-env is ONLY for session / user jobs
[17:09] <AnrDaemon> And upstart will track wrong PID.
[17:09] <chras> NOT jobs managed by upstart pid=1
[17:10] <AnrDaemon> Nice suggestion, dude, I TOLD YOU that's not an option.
[17:10] <frew> gracious
[17:10] <chras> AnrDaemon: with all honesty, you need to chill out on the attitude a little
[17:10] <AnrDaemon> set-env works if job is run as root.
[17:10] <AnrDaemon> (Which counts as user job, from upstart POV)
[17:11] <chras> well i'll test this
[17:11] <AnrDaemon> I love upstart. I really do. But these caveats is what driving the bar down.
[17:12] <frew> chras: btw not sure if you are the right person to mention this to, but the link to the upstart revision control here (http://upstart.ubuntu.com/development.html) is broken.
[17:12] <AnrDaemon> It was broken for years since announcement that Debin switched to systemd.
[17:12] <AnrDaemon> Debian anyway.
[17:13] <frew> I think it just needs to be ~upstart-devel instead of ~scott
[17:14] <chras> frew: im just a user
[17:14] <chras> trying to help other people out
[17:14] <frew> gotcha
[17:14] <chras> so they dont have to drown in systemd
[17:14] <frew> hah
[17:15] <AnrDaemon> Speaking of which. May be it isn't new for you, but I just recently found https://wiki.ubuntu.com/SystemdForUpstartUsers
[17:15] <chras> [t] 17:15:22 root@t-nfs04a:/etc/event.d# initctl set-env TEST2=chris
[17:15] <chras> initctl: Not permissible to modify PID 1 job environment
[17:15] <AnrDaemon> Of course not.
[17:16] <AnrDaemon> But try it in a single job.
[17:16] <chras> that means set-env isnt really an option
[17:16] <AnrDaemon> You can change the JOB's environment.
[17:16] <AnrDaemon> In pre-start.
[17:16] <AnrDaemon> And then straightforward exec using these altered variables.
[17:17] <AnrDaemon> Instead of bugus scripting.
[17:17] <chras> thats just as much bogus scription
[17:17] <AnrDaemon> But then upstart will track the PID of the service itself.
[17:17] <chras> hes looking for an alternative to doing an env=SOMETHING , and you're suggesting doing an env=SOMETHING in essense
[17:17] <AnrDaemon> With no guesswork.
[17:17] <AnrDaemon> As I said, he's doing the right thing in a wrong way.
[17:18] <AnrDaemon> If he want isolation, he should use isolation tools.
[17:33] <frew> AnrDaemon: I don't think I ever said I wanted isolation.
[17:34] <AnrDaemon> No, you didn't. But your description clearly pointed to your intentions.
[17:34] <frew> eh, strain at the tea leaves if you want.
[17:35] <frew> /mnt/tmp is a sep physical disk
[17:35] <AnrDaemon> Even better.
[17:35] <chras> well, arguably tmpspace by design is supposed to be volatile
[17:35] <frew> yeah, on my laptop I set TMPDIR to /run/shm
[17:36] <AnrDaemon> I'm running a container that mounting 3 BTRFS subvols directly, that aren't mounted at all on host.
[17:36] <frew> but ofc if somethign wrote a 30G file there things would go poorly.
[17:36] <chras> right
[17:36] <AnrDaemon> Applications that write 30Gb temps usually have configuration for scratch space.
[17:37] <chras> yeah, that type of thing, especially if it needs to be persistant, should be outside of system tmp most likely
[17:41] <frew> chras: yeah I'm thinking of giant crash file type things
[22:16] <django000> Hello everyone, I am trying to write my first configuration file, but I can't figure out what runlevel means?
[22:16] <django000> Could anyone help me please?
[22:16] <django000> Thanks
[22:17] <AnrDaemon> Nothing, you shouldn't use runlevels.
[22:19] <django000> AnrDaemon: most of the examples I find online have runlevels, I am just curious about its meaning, thanks for helping out
[22:20] <AnrDaemon> It's an anciet initd concept.
[22:20] <AnrDaemon> You can easily google the full documentation. But you SHOULD NOT use runlevels. Unless you actually know what you are doing.
[22:21] <AnrDaemon> If it is a sinmple system service, "start on filesystem" should be enough. If it uses network, "start on filesystem and net-device-up IFACE != lo" would suffice majority of cases.
[22:22] <AnrDaemon> Details are in the channel title's link.
[22:23] <django000> I just want to run a python script on the background, It should be running all the time. I did some research and found out about upstart
[22:23] <AnrDaemon> Oh, and if your service uses forking to drop privileges, you better teach it to forget this bullshit and use setuid/setgid in the script itself instead.
[22:23] <django000> so yeah, I have just basic understanding for now
[22:24] <django000> reading the manual :)
[22:24] <AnrDaemon> Then it's rather straightforward.
[22:24] <AnrDaemon> Literally, no more than 5 lines of code to start a service.
[22:24] <AnrDaemon> 2 of them being informational :D
[22:25] <django000> :), uff I wish I know the other 3 lines to complete my 5
[22:26] <django000> But I am still curious, sorry
[22:26] <django000> so I think I will continue with my search
[22:29] <AnrDaemon> django000: Just a moment.
[22:33] <AnrDaemon> django000: http://pastebin.com/uqSdZZME
[22:35] <AnrDaemon> However, if you want it to run as non-root, that's going to be a little more work on the details.