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