=== khermans__ [i=administ@nat/cisco/x-361219dbbc0b826a]  has joined #upstart
=== theCore [n=alex@ubuntu/member/theCore]  has joined #upstart
=== Md [i=md@freenode/staff/md]  has joined #upstart
=== Md [i=md@freenode/staff/md]  has joined #upstart
=== administrator_ [i=administ@nat/cisco/x-fedbc0ca9b370c8d]  has joined #upstart
=== j_ack [n=rudi@p508D95BA.dip0.t-ipconnect.de]  has joined #upstart
=== int0x0c [n=ben@161.253.47.94]  has joined #upstart
=== int0x0c [n=ben@161.253.47.94]  has joined #upstart
=== int0x0c [n=ben@161.253.47.94]  has joined #upstart
=== Amaranth [n=travis@ubuntu/member/Amaranth]  has joined #upstart
=== administrator_ [i=administ@nat/cisco/x-607c23dd90cafeb8]  has joined #upstart
=== mbiebl [n=michael@dialin-145-254-249-245.pools.arcor-ip.net]  has joined #upstart
=== phsdv [n=paul@dyn-88-122-33-87.ppp.tiscali.fr]  has joined #upstart
=== pkt [n=pantelis@85.75.171.157]  has joined #upstart
=== pkt [n=pantelis@athedsl-285854.otenet.gr]  has joined #upstart
=== Md [i=md@freenode/staff/md]  has joined #upstart
=== Amaranth [n=travis@ubuntu/member/Amaranth]  has joined #upstart
=== _ion [i=johan@kiviniemi.name]  has joined #upstart
=== j_ack [n=rudi@p508DB43F.dip0.t-ipconnect.de]  has joined #upstart
=== phsdv [n=paul@dyn-88-122-33-87.ppp.tiscali.fr]  has joined #upstart
=== administrator_ [i=administ@nat/cisco/x-1a796513494e6b04]  has joined #upstart
=== Keybuk [n=scott@wing-commander.netsplit.com]  has joined #upstart
[09:09] <Keybuk> *bounce*
[09:09] <AlexExtreme> hey
[09:09] <AlexExtreme> i'll test out 0.3.7 tomorrow hopefully
[09:09] <Keybuk> cool
[09:09] <Keybuk> I've not had any death threats yet, so it seems to be working
[09:09] <AlexExtreme> heh
[09:13] <Keybuk> already thinking what to put in the next version
[09:13] <Keybuk> think the big change will have to be re-implementing restart
[09:39] <_ion> keybuk: The resources idea sounds great.
[09:39] <Keybuk> difficult it is deciding which state it needs to stay in
[09:39] <Keybuk> start/waiting I gues
[09:40] <_ion> keybuk: It would be nice if a shell script could make the 'uses' information.
[09:41] <_ion> E.g. block-device-added could find out the actual physical device for any of /dev/sda1, /dev/mdsomething and /dev/lvm-volumegroup/something, and say 'uses $DISKNAME' based on that.
[09:42] <_ion> s/block-device-added/the fsck job/
[09:43] <Keybuk> why would the disk size make a difference?
[09:43] <_ion> Size?
[09:43] <Keybuk> oh
[09:43] <Keybuk> dunno where I read that
=== Keybuk blames the wine
[09:43] <_ion> :-)
[09:45] <Keybuk> yeah, the problem there is you'd have to either include that in the event, or compute it in the jobs
[09:46] <Keybuk> I'm inclined to suggest the event is better there though, since it probably *has* that information in the first place
[09:47] <Keybuk> and it's cheaper than calculating it on every single job
[09:47] <_ion> Good point.
[09:47] <Keybuk> it's just DEVICE=$(readlink /sys$DEVPATH/device) after all
[09:52] <_ion> For LVM and MD, /sys/block/$foo/slaves seems to be the right way to find the physical device.
[09:53] <Keybuk> yeah, it'd be annoying to code all the different logic into the "check the filesystem" event
[09:53] <Keybuk> uh job
[09:53] <Keybuk> AND any other job that wants it
[09:53] <_ion> True.
[09:53] <Keybuk> much easier to handle it in the specific events
[09:53] <Md> be sure to check a > 2.6.20 kernel with the compat sysfs links disabled :-)
[09:53] <_ion> Oh, 'slaves' is deprecated?
[09:54] <Keybuk> no, device is going away
[09:54] <_ion> Ah
[09:54] <Keybuk> because /sys/block/hda itself is a symlink
[09:54] <Keybuk> like I said, much easier to put this into the event emission
[09:55] <Keybuk> Md: that hasn't happened yet though?
[09:55] <Md> what?
[09:56] <Keybuk> the move of block devices to under the physical device
[09:56] <Keybuk> (which means the device symlink is still necessary)
[09:57] <Md> I am not sure, I had to roll back because the 2.6.21rcsomething rawhide kernel broke resume from RAM on my system (any clue about how to debug this? the screen is not working, but I can reboot using magic sysrq)
[09:57] <Keybuk> 2.6.20 here, /block/hda is still a directory
[09:58] <Keybuk> that may be caused by the deprecated option though, looking at the code
[09:58] <Keybuk> might have to try turning it off and see what happens
[09:59] <AlexExtreme> wait
[09:59] <AlexExtreme> umm
[09:59] <AlexExtreme> wrong channel
[09:59] <AlexExtreme> sorry
[10:15] <cortana> dumb question, perhaps, but how stable are the contents of /sys?
[10:16] <Md> not much so far
[10:17] <Keybuk> about as stable as upstart's job definition syntax :p
=== phsdv [n=paul@dyn-88-122-33-87.ppp.tiscali.fr]  has joined #upstart
[10:26] <_ion> Excuse my ignorance, but what's the correct way to find the corresponding /sys/block/... path for a file in /dev, e.g. sda*, md*, mapper/*? Comparing the contents of /sys/block/**/dev to the device types of the /dev files probably works, but there's a better way, isn't there?
[10:27] <Md> _ion: udevinfo -n I think
[10:28] <Keybuk> udevinfo -q path -n hda1
[10:28] <Keybuk> though you're not *really* supposed to use udevinfo as a database <g>
[10:29] <_ion> Thanks. Works for sda1 and md0, but not /dev/mapper/*.
[10:29] <Keybuk> did you try dm-0 as the name?
[10:29] <Md> _ion: because these are not managed by udev
[10:29] <Keybuk> udevinfo -q path -n dm-0
[10:29] <Keybuk> Md: they are in Ubuntu
[10:30] <_ion> "no record for 'dm-0' in database" (an Edgy box)
[10:32] <Keybuk> hmm
[10:32] <Keybuk> dunno how to make a devmapper device
[10:32] <Keybuk> dmsetup create foo just blocks
[10:33] <Keybuk> ah
=== Keybuk pressed ^D
[10:33] <Keybuk> wing-commander scott# udevinfo -q path -n mapper/foo
[10:33] <Keybuk> /block/dm-0
[10:39] <_ion> Funny, doesn't work here.
[10:48] <Keybuk> hmm
[10:48] <Keybuk> feisty?
=== j_ack [n=rudi@p508DB43F.dip0.t-ipconnect.de]  has joined #upstart