[09:40] Hey all === JohnFlux_ is now known as JohnFlux [09:41] I come in here every month to check on the status of upstart and dbus :) [09:41] Is it now possible to communicate via dbus to upstart to start/stop/restart/etc services? [09:41] if not dbus, then some other method [09:46] I know you guys are busy, but if I can communicate to upstart, then I can add this functionality to the kde task manager [09:46] then users can easily start and restart services [10:12] well, trivially you can communicate with it using initctl stop/start/status/etc... [10:25] atsampson: well, I'll need to know the pid of the process as well [10:25] and just running initctl status won't be very reliable. presumably the output could change [10:25] initctl'll tell you that; "nmbd (start) running, process 1254" [10:25] between distros, with versions etc [10:26] it looks from the man page as if the output's designed to be parsed [10:26] also there'd be no notification if the status changes etc [10:26] I think someone was working on dbus interface [10:27] dunno how far along that got [10:27] you can say "initctl jobs" to get notifications about job state changes [10:27] how does that work? [10:27] well, you run "initctl jobs", and it prints a parseable line to stdout for each state change [10:28] hmm, it needs to be run as root? [10:28] is that a bug? [10:28] yes, it does, and no, it would be a bug if you could modify system services as a non-root user, surely? [10:29] why would monitoring them be modifying the system services? [10:30] why wouldn't monitoring system services be a privileged operation? [10:30] (disclaimer: I'm just a user of upstart, so please feel free to ignore anything I say...) [10:31] atsampson: hmm [10:32] atsampson: 'ps' doesn't require root, and you could monitor whether services start/stop through that [10:32] although not very efficently [10:32] if I'm using upstart to manage services on a machine with untrusted users, I probably don't want them seeing the details of all the services I'm running [10:32] I can see that there might be sensitive information [10:32] but for just simple status changes, that should be public knowledge [10:32] a normal user can run 'status apache' etc [10:33] ps does require root on some systems, at least to see processes that aren't yours (there's at least one kernel patch for Linux that provides sensible permissions on the files on /proc, for example) [10:33] hmm, wait no they can't [10:33] a normal user can do /etc/init.d/apache2 status [10:33] but not status apache2 [10:33] that's very strange [10:34] start/stop/status are just symlinks to initctl; "start" = "initctl start" [10:34] atsampson: the vast vast majority of users aren't going to be filternig ps [10:34] atsampson: hum [10:34] that's really wrong [10:34] erm, no, it's not... [10:34] checking if apache is running should not require root [10:34] just check whether the pid is there [10:35] atsampson: why would /etc/init.d/apache2 status not require root, but status apache2 does ? [10:35] if you want that behaviour, I think it'd be better to put it somewhere other than upstart [10:36] s/would/should/ [10:36] it seems a bit silly to put lots of complicated access control stuff into init, rather than having some other daemon/service that can make requests to upstart on your behalf and do access control [10:36] atsampson: well, I want to be able to show the list of running services to the user in the kde task manager [10:37] so perhaps the solution'd be to have a daemon that spoke the upstart protocol to init on one side, and dbus to other processes, and then you could configure that to do access control? [10:37] `hmm [10:37] how does initctl work? [10:38] init's got to be as simple, reliable and secure as possible, really [10:38] how does it check the status of a process? [10:38] * atsampson straces [10:38] it talks over a Unix socket to init, it appears [10:38] ah hmm [10:39] there's a library in the upstart package that wraps up the protocol, so it could presumably be used in something else without too much trouble... [10:40] presumably that requires root privillages as well? [10:40] yes [10:40] hum [10:42] * atsampson decides it's a good time for tea [10:42] it's always a good time for tea :) [10:44] :) [10:46] I suspect I'm going to have to make a small setuid root program that just calls initctl statu [10:46] s [10:47] :-/ [10:47] or provide a bit of sudo config... [10:47] well, users aren't going to want to type in a root password just to see what is running [10:47] i don't think any other OS does that [17:47] JohnFlux: sorry, wasn't around to answer your questions earlier [17:47] is it possible to communicate via dbus? no, not today [17:47] will it be? yes, in trunk - there's only one thing higher on the todo list now [17:47] is it possible by any other method today? yes, released versions use a custom IPC protocol [17:48] you can use that through initctl [17:48] or use libupstart (which initctl is a CLI wrapper for) [17:48] obviously the library is deprecated, and doesn't even exist in trunk [17:48] the initctl output is intended to be parsed by humans and machines [17:48] but obviously may change with the DBus change [17:48] why root only? [17:49] simple: avoids local-root security exploits due to bugs in the initctl protocol [17:49] dbus would solve that since non-root requests can be made through the dbus daemon [18:27] Keybuk: hey [18:28] Keybuk: thanks for the reply [18:28] Keybuk: It would be awesome to get this information via dbus, as a non-root user [18:28] Keybuk: I'll wait for that :-) [19:22] Hi everybody [19:24] I'd like to post a question here regarding switching of runlevels: [19:24] I'm running Ubuntu Gutsy (Server Edition), and would like to run a script I wrote [19:25] that backs up an entire HD to external media [19:25] However, I'd like to first switch to a "runlevel" that's similar to single-user mode [19:25] Basically, I don't want any crucial background process running while the script executes [19:26] And afterwards, I'd like to go back to the "runlevel" I came from (probably 2?) [19:26] Does anyone here know how I might accomplish that? [19:32] telinit 1 [19:32] that switches you to single-user mode [19:33] HI [19:33] Right. No I got the general idea [19:34] But how do I control the flow of things? [19:34] can I run telinit 1, and the next call my script, and then telinit 2? [19:37] I'm not sure I follow, sorry [19:38] Right. And I know that upstart is really an event-driven model. [19:38] But since it's being used as a so-called SysV Init replacement... [19:39] Anyway, let me try to be more specific: [19:39] I wrote a script, called bootbak, [19:39] That script reformats an external hard USB drive (250GB Maxtor) [19:40] and then copies the entire filesystem to that drive, modifies /etc/fstab and grub/menu.lst, [19:40] and writes an appropriate MBR to it so I can boot of the USB HD in case of total system failure [19:41] Now, the server to be backed up is an email server which receives tons of emails, especially during the night (SPAM, sigh) [19:42] Why not install multiple HDDs and use redundancy? [19:42] That aside, what I was thinking is to bring down all services, like postfix, dovecot, apache a.s.f. [19:43] ion_: eventually, we will install multiple USB HD on a hub and run that script each day against a different drive [19:43] for rotation [19:43] Point is, to make it short: I'd like to do this: [19:44] init 1 [19:44] I mean, multiple internal HDDs and RAID-1 or higher. [19:44] /usr/local/bin/bootbak [19:44] init 2 [19:44] does that work in SysVinit? [19:44] ion_: Well, we want to have backups in case we mess up our configurations so bad that we can't get the server up and running again [19:45] Keybuk: That's exactly it. It doesn't... [19:45] init 1, at the end of it, kills ALL processes, including the script itselve [19:46] pretty much, yes [19:46] I don’t really see why you’d need to kill the services to do backups. [19:46] First off, inconsistencies. The backup runs for >5minutes [19:47] during which time many emails could have come in, etc [19:47] MySQL is also running on that server [19:47] Anyway, I know I can run the script in runlevel 2 while everything is up and running. [19:48] The new emails would go to the next backup. [19:48] Right now however, I'm the only user on that server (it's a new box) [19:48] You probably should take plaintext dumps of the database. [19:49] ion_: I understand. [19:51] ion_: Let's pretend for a moment [19:51] Is it possible to control the system in such a way that you could switch it into a different runlevel temporarily [19:52] in order to do whatever maintenance tasks [19:52] and then bring it back up? [19:52] (All automated of course) [19:55] Maybe upstart is just not the right tool for that? [19:55] Here's what I had in mind: create a job in /etc/event.d that listens to trigger run-bootbak, [19:56] then add a crontab entry for, say, 10pm that runs initctl emit run-bootbak === AndyP_ is now known as AndyP [22:54] presumably you could have another runlevel that's like 1, but rather than sulogin runs the backup script then switches back to runlevel 2 when it's finished...