| === 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 | ||
| 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 | 12:19 |
|---|---|---|
| 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:53 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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. | 16:59 |
| 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:00 |
| 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:01 |
| frew | AnrDaemon: ...what are you talking about? | 17:02 |
| chras | AnrDaemon: why not? | 17:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| frew | I think it just needs to be ~upstart-devel instead of ~scott | 17:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| AnrDaemon | If he want isolation, he should use isolation tools. | 17:18 |
| frew | AnrDaemon: I don't think I ever said I wanted isolation. | 17:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| chras | yeah, that type of thing, especially if it needs to be persistant, should be outside of system tmp most likely | 17:37 |
| frew | chras: yeah I'm thinking of giant crash file type things | 17:41 |
| 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:16 |
| AnrDaemon | Nothing, you shouldn't use runlevels. | 22:17 |
| django000 | AnrDaemon: most of the examples I find online have runlevels, I am just curious about its meaning, thanks for helping out | 22:19 |
| 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:20 |
| 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:21 |
| AnrDaemon | Details are in the channel title's link. | 22:22 |
| 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:23 |
| 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:24 |
| django000 | :), uff I wish I know the other 3 lines to complete my 5 | 22:25 |
| django000 | But I am still curious, sorry | 22:26 |
| django000 | so I think I will continue with my search | 22:26 |
| AnrDaemon | django000: Just a moment. | 22:29 |
| AnrDaemon | django000: http://pastebin.com/uqSdZZME | 22:33 |
| AnrDaemon | However, if you want it to run as non-root, that's going to be a little more work on the details. | 22:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!