=== khermans__ [i=administ@nat/cisco/x-a26699e7bddfb183] has joined #upstart
=== _ion_ [i=johan@kiviniemi.name] has joined #upstart
=== Md [i=md@freenode/staff/md] has joined #upstart
=== khermans__ [i=administ@nat/cisco/x-9f20569141d3680c] has joined #upstart
=== urban [n=urban@xa147.internetdsl.tpnet.pl] has joined #upstart
urbanhi, how can i deny sshd service to start more than once?08:46
=== juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart
=== Md [i=md@freenode/staff/md] has joined #upstart
=== pkt [n=pantelis@athedsl-292060.otenet.gr] has joined #upstart
=== Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart
=== reppel [n=reppel@213-140-11-128.fastres.net] has joined #upstart
=== Keybuk has a think how "status" and "list" should work
_ionWell? :-)06:10
Keybukstill thinking06:16
Keybukthe typical problem can be defined as the "I just upgraded apache but haven't restarted it yet" one06:16
Keybukyou'd have an apache job, marked for deletion, that's still running06:16
Keybukand a newer version of the apache job that's no longer running06:17
Keybukyou'd want "status apache" to show them bove06:17
Keybuk# status apache06:17
Keybukapache (start; deleted) running, process 1234506:17
Keybukapache (stop) waiting06:17
Keybukin which case, that's identical to "list" :p06:18
_ionPerhaps list should accept a search pattern, so 'list apache' as well as 'list pach' would list both of them, but 'status apache' would be guaranteed to list only zero or one entries; in that case, "apache (start; deleted) running, process 12345".06:20
Keybukso what criterion would status use to determine which one of the multiple apache jobs to return?06:20
_ionThe one that is running. :-) But that criterion fails if there are multiple instances running simultaneously...06:22
_ionIn the case of a single instance and an updated config file, the "apache (stop) waiting" would be kind of redundant information from the user's point of view, as the previous line already says "deleted".06:23
_ionThis is just thinking out loud, i definitely haven't thought the whole thing through. :-)06:25
Keybukyou can technically start the new apache without first stopping the old one06:25
_ionI'm not sure that should be allowed, if the conffile doesn't allow instances.06:26
Keybukaye, not sure how to prevent that yet :p06:27
_ionapache (deleted) running, apache (stop) waiting: any goal changes apply to the former, *until* it reaches the 'waiting' state. Then it vanishes and goal changes apply to the latter.06:29
Keybukwhat if the two have different event matches, and the event sequence for the newer one happens? :p06:30
_ionGood question. :-)06:30
Keybukfor instance jobs, this gets even more interesting :p06:31
Keybukfor those, you probably *do* want the newer one to be the one that's started, and not the older one06:31
_ion"what if the two have different event matches, and the event sequence for the newer one happens?" Intuitively, i'd expect upstart to ignore that, until the running, deleted job is gone. Or can you think of a reason that would be a bad thing?06:34
Keybukinstance jobs06:35
_ionYeah, i specifically meant non-instance jobs.06:35
Keybuknot off-hand06:35
_ionThe rules would be different for instance jobs.06:36
Keybukdefining a sensible set of rules is the tricky bit ;)06:36
_ionAnother interesting question: what happens if a job's multi-instance flag is changed :-)06:36
Keybukhow can it be changed?06:36
_ionI mean, the deleted conffile says 'instance' and the new one doesn't, or vice versa.06:37
Keybukthe new conffile creates a new job06:37
Keybukthat's kinda the point :p06:37
Keybukand why you end up with deleted jobs for the old conffile06:37
_ionYes. I mean:06:39
Keybukoh, you mean wrt instance behaviour?06:39
Keybukyes, I see your point06:39
_ionIf there's a rule that:06:39
_ion not 'instance': the new one can't be started if the old one is still running06:40
_ion 'instance': new instances are started based on the new conffile's rules06:40
_ionwhat to do when the 'instance' is changed :-)06:41
Keybukwe could define the following rule06:41
Keybuk * For any job name, there is one master job that holds that name.06:41
Keybuk * That job may have multiple instances06:42
Keybuk * That job may also have a potential replacement06:42
Keybuk-- 06:42
Keybukparsing a new conffile, would locate the existing job, destroy any existing replacement, and place itself as the replacement of that job06:43
Keybukit would not be a "master" until the job it replaces has been deleted06:43
Keybukinstances are also not a "master" because they're an instance of another job06:44
Keybukstart, stop & status would all operate on the current master job06:44
Keybukthey may also, through specific job id, operate on an instance of the job06:44
Keybukbut may never operate on a replacement job while the master exists06:45
_ionwould stopping the master job kill all the instances?06:45
Keybukgood question06:45
Keybukthe above would solve the instance/not-instance problem -- whatever flag is "current" applies, and applies until the current job is gone06:46
_ionFrom the point of a daemon's postinst script, it might be best if it's certain 'stop foobard && start foobard' actually kills any instances of the old version. It might be a critical security update.06:48
=== khermans__ [i=administ@nat/cisco/x-a91f49d7ef5e7be9] has joined #upstart
Keybukshould sysadmins be allowed to explicitly start a replacement job by id?07:04
_ionWhat would be an use case for that?07:06
Keybukwhat would be the use case for not allowing that?07:06
Keybukif they've identified it explicitly by id, should that be considered valid?07:07
_ionSorry, i'm not exactly sure what you mean by starting a replacement job by id. Is that the id of an instance?07:08
Keybukall jobs have a unique id07:08
=== theCore [n=alex@ubuntu/member/theCore] has joined #upstart
Keybukso you can do something like07:08
Keybuk# initctl list -v apache07:08
Keybukapache [#1234]  (start) running, process 1234507:08
Keybukapache [#1980]  (stop) waiting07:08
Keybuk# 07:08
Keybukwhere the 1980 one is the "new" replacement for the other07:09
Keybukif you then did07:09
Keybuk# start --id 198007:09
Keybukshould it give you an "unknown job" error, because it's not yet replaced #1234, or should it just do it since you were explicit07:09
_ionI'm still thinking it should be enforced that no two apaches can be running simultaneously if it's not an 'instance' job.07:10
Keybukeven though the sysadmin was clearly trying?07:11
Keybukit's easy enough to add some code to enforce that07:11
_ionYes, even though she was clearly trying. :-) But that's only my personal opinion.07:12
_ionThere could be an informal message, like "Please stop the deleted job before starting the new one".07:13
_ionIf the job doesn't specifically say 'instance', i think it's a mistake from the sysadmin to try to force multiple instances to run.07:15
_ionE.g. apache: the second instance is going to try to listen on the same port, write to the same logfiles, etc.07:15
Keybukso how about the following:07:19
Keybuka job is in the DELETED state if07:20
Keybuk- it's an instance which has finished07:20
Keybuk- it's a non-instance or instance-less job that has been replaced07:20
Keybukwhen we move a job with a replacement into the DELETED state, we unmark the replacement so it becomes the new master07:20
Keybukwhen finding a job by name, we never return instances or replacements07:21
Keybukwe don't allow spawning an instance, changing the goal or handling events for DELETED jobs or replacements07:21
Keybuk(technically we don't allow spawning an instance of instances either, but that's handled differently by redirection)07:22
_ionSounds good.07:23
_ionHmm, perhaps present the job IDs to the user in base-36? :-) '1234' would be 'ya' and '1980' would be '1j0'. They'd be shorter and perhaps even easier to remember.07:24
Keybukso, "start apache" would only ever start the current version07:26
Keybukit'd say unchanged if it was running, might spawn a new instance, or just start the real thing07:26
Keybuk"stop apache" would stop the current version07:26
Keybukit'd say unchanged if it was running, might stop all instances, or just stop the real thing07:26
Keybuk"status" apache would query the current version07:27
Keybukit might return a single status, or a list of instances with the master first07:27
=== j_ack [n=rudi@p508DC039.dip0.t-ipconnect.de] has joined #upstart
=== Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart
Keybukdunno what next door are doing10:17
Keybuklots of banging and drilling sounds10:17

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!