[Rack] door still is not working - too many baron.py instances!
Jake
jake at spaz.org
Wed Jul 31 00:31:53 UTC 2013
it seems that gateman is not working, and we are getting 500 errors from
the API server again, so maybe the baron.py proliferation is related to
that problem.
how does gateman work? can't someone just write a program that directly
talks to the USB hardware to make it open the door?
is gateman an executable or a daemon or what? something about socket
30012?
On Tue, 30 Jul 2013, Sharp Hall wrote:
> Ouch! Does baron.py work when started from the commandline? Maybe as a
> quick fix you could remove baron.py from monit and put it in rc.local?
>
> -sharp
>
> On 07/30/2013 04:56 PM, Jake wrote:
>> this afternoon (tuesday 4:30pm) the payphone was unresponsive. I logged
>> into minotaur and was greeted with
>>
>> Last login: Mon Jul 29 22:52:24 2013 from 172.30.1.30
>> -bash: fork: Cannot allocate memory
>> jake at minotaur:~$
>>
>> any command i tried failed with the same error, so i told it to reboot.
>>
>> after the reboot, i see that there are four instances of baron.py - two
>> for upstairs and two for downstairs. that is a problem.
>>
>> help!
>>
>>
>> On Tue, 30 Jul 2013, Jonathan Lassoff wrote:
>>
>>> OK -- I think I've kicked it into shape. pidfiles for baron are now
>>> created by the baron process and are in /var/run/baron.
>>> Hopefully that should fix things a bit.
>>>
>>> Happy hacking,
>>> jof
>>>
>>>
>>> On Tue, Jul 30, 2013 at 12:37 AM, Jonathan Lassoff <jof at thejof.com>
>>> wrote:
>>> Hrm... looking.
>>> There should be two baron instances (upstairs and down), but it looks
>>> like there are a shitload of downstairs running. The
>>> /var/log/monit.log tells the story:
>>>
>>> [PDT Jul 30 00:24:53] error : Alert handler failed, retry scheduled
>>> for next cycle
>>> [PDT Jul 30 00:24:53] error : 'baron_downstairs' process is not
>>> running
>>> [PDT Jul 30 00:24:53] info : 'baron_downstairs' trying to restart
>>> [PDT Jul 30 00:24:53] info : 'baron_downstairs' start: /bin/su
>>> [PDT Jul 30 00:25:24] error : 'baron_downstairs' failed to start
>>>
>>>
>>> Looks like monit is targeting the process to monitor by the pidfile,
>>> however it looks like the downstairs instance isn't creating a pidfile.
>>> It should be writing to /var/run/baron_downstairs.pid, but the file
>>> doesn't exist, and /var/run is only writable by root, so I would guess
>>> that it's just failing to create that file (the daemon
>>> runs as "baron").
>>>
>>> I'm going to create a /var/run/baron directory for pidfiles to land,
>>> but another cromulent fix would be to use start-stop-daemon as root
>>> and have that create the pidfile as it forks the
>>> "baron"-owned process.
>>>
>>> Update in a minute....
>>>
>>>
>>> On Tue, Jul 30, 2013 at 12:25 AM, Jake <jake at spaz.org> wrote:
>>> but it only works upstairs, not on the payphone. i'm sure there
>>> are multiple baron.py running on it is why, why does that happen?
>>>
>>> i'm on bart i cant log into minotaur
>>>
>>> On Tue, 30 Jul 2013, Jonathan Lassoff wrote:
>>>
>>> Fuck yeah! Phew.Thanks for bringing this to my attention.
>>>
>>>
>>> On Tue, Jul 30, 2013 at 12:06 AM, Jake <jake at spaz.org> wrote:
>>> yay it fucking works!
>>>
>>> On Tue, 30 Jul 2013, Jonathan Lassoff wrote:
>>>
>>> I unloaded and re-probed the device (rebooting the
>>> controller on
>>> it), and now it seems to be talking again.Weirdness!
>>>
>>>
>>> On Mon, Jul 29, 2013 at 11:52 PM, Jonathan Lassoff
>>> <jof at thejof.com>
>>> wrote:
>>> I fixed it, but now any parallel port-related
>>> ioctls are not
>>> working on the device.
>>> Something is really weird with that USB Parallel
>>> port adapter right
>>> now. Could we try moving it to another port, making
>>> sure the wires
>>> aren't touching anything weird, or try
>>> unplugging/replugging it?
>>>
>>> It'd be really cool if we could make some proper
>>> interface hardware
>>> sometime.
>>> What do you think about making a little arduino with
>>> some
>>> optoisolators that we can use to talk serial to?
>>>
>>> --j
>>>
>>>
>>> On Mon, Jul 29, 2013 at 11:49 PM, Jonathan Lassoff
>>> <jof at thejof.com>
>>> wrote:
>>> So, I can see that gateman is failing to start
>>> because
>>> /dev/parport0 is failing to get created and
>>> owned/writable by the
>>> "lp" group. This is how gateman accesses this.
>>> That device seems to be getting repeatedly re-probed
>>> or something.
>>>
>>> Manually fixing up...
>>>
>>>
>>> On Mon, Jul 29, 2013 at 11:48 PM, Jake
>>> <jake at spaz.org> wrote:
>>> i and sharp are here too, sharp is much
>>> sharper than i am
>>> though and he is digging down to the root of the
>>> problem.
>>>
>>> but we have to leave on the last bart.
>>>
>>> On Mon, 29 Jul 2013, Jonathan Lassoff wrote:
>>>
>>> Eep! I'm bummed that this is broken.
>>> I'm poking around on minotaur to try and
>>> see what's up.
>>> Those errors from api are because it couldn't check
>>> the gate ringing
>>> status from gateman.
>>>
>>> --j
>>>
>>>
>>> On Mon, Jul 29, 2013 at 11:42 PM, Jake
>>> <jake at spaz.org>
>>> wrote:
>>> help!!!! it's not working!!!
>>>
>>> me and sharp are trying to fix it
>>> but.. we need
>>> you jof
>>>
>>> this gateman shit is not working
>>> at all. we tried
>>> the mknod thing and...
>>>
>>> help! the door can't be opened!
>>>
>>> -jake
>>> 415-533-3699
>>> (leaving by midnight)
>>>
>>> On Sat, 6 Jul 2013, Jonathan
>>> Lassoff wrote:
>>>
>>> Ok, I did some security,
>>> packaging, and
>>> general FIXME work on gateman,
>>> and have it running now.
>>>
>>> We may need to run this if
>>> the box reboots.
>>> I'l still not sure about
>>> fixing udev the right way.
>>>
>>> sudo mknod /dev/parport0 c
>>> 99 0
>>> sudo service gateman status
>>> || sudo service
>>> gateman start
>>>
>>> On Sat, Jul 6, 2013 at 3:56
>>> PM, Jonathan
>>> Lassoff <jof at thejof.com> wrote:
>>> So, I figured out that
>>> /dev/usb/lp0 is
>>> actually a line printer emulation device.
>>> /dev/parport0 was
>>> still what I wanted
>>> (99, 0), but udev wasn't creating it.
>>>
>>> I manually did a mknod
>>> for it, but now
>>> just need to figure out how to
>>> get it to survive
>>> reboots.
>>>
>>> --j
>>>
>>> On Sat, Jul 6, 2013 at
>>> 2:12 PM,
>>> Jonathan Lassoff <jof at thejof.com> wrote:
>>> On Sat, Jul 6,
>>> 2013 at 3:17 AM,
>>> Jake <jake at spaz.org> wrote:
>>> we have
>>> been spamming the
>>> discuss list with this stuff. no more.
>>>
>>>
>>> Oh... yeah, I
>>> suppose rack@ is
>>> more appropriate.
>>> However, I think
>>> we're more
>>> on-topic in this thread than most of the
>>> other threads :p
>>>
>>> it may be
>>> an issue of the
>>> old hardware having a "real" parallel port that we
>>> never
>>> used, because we
>>> didn't have a connector for it, and the new hardware
>>> doesn't
>>> have a real
>>> parallel port.
>>>
>>>
>>> Certainly possible.
>>> However, since
>>> it's the USB
>>> emulator in both cases. I'm unsure exactly
>>> what is breaking.
>>>
>>> make sure
>>> you're talking
>>> to the right device, which is a USB parallel port
>>> which is
>>> tied to the
>>> sprinkler pipe just above the wall-o-tubes.
>>>
>>> i guess
>>> you're looking at
>>> /dev/usb... so it should be the right device.
>>>
>>> it must be
>>> something about
>>> the new OS install, different drivers for the usb
>>> parallel
>>> port or something
>>> fucked up like that. good luck.
>>>
>>>
>>> I think I'm
>>> talking to the right
>>> device. Both kernels used the uss720
>>> driver, however
>>> I was getting at
>>> it as /dev/parport0 (hard-coded into
>>> gateman :( ),
>>> whereas now there
>>> seems to be a device at /dev/usb/lp0.
>>>
>>> It's major
>>> number 180, minor 0,
>>> which the device listing
>>>
>>>
>>> (http://www.mjmwired.net/kernel/Documentation/devices.txt#2531)
>>> shows
>>> as 0 =
>>> /dev/usb/lp0 First USB
>>> printer.
>>>
>>> I wonder if I'm
>>> trying to
>>> bit-bang to something that is supposed to be
>>> a printer, and
>>> that is getting
>>> in the way.
>>>
>>> I'll keep
>>> hacking and
>>> experimenting. Any kernel hackers looking for a
>>> short
>>> exploration are encouraged
>>> to get in touch.
>>>
>>> Cheers,
>>> jof
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
More information about the Rack
mailing list