Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
pbbuttonsd - ERROR: Server is already running
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on PPC
View previous topic :: View next topic  
Author Message
gordin
Guru
Guru


Joined: 11 Oct 2002
Posts: 300
Location: Germany/WI

PostPosted: Tue Mar 16, 2004 10:08 pm    Post subject: pbbuttonsd - ERROR: Server is already running Reply with quote

Hi,

after an update of pbbuttonsd to version 0.5.9 I always get the error
ERROR: Server is already running. Sorry, only one instance allowed.
But there is no instance of pbbuttonsd running.
Someone in this forum had a similar problem and could solve it with a reboot and deleting /dev/mixer
This does not work for me
Switching back to 0.5.8 does not help.
Any ideas?
Back to top
View user's profile Send private message
Pylon
Retired Dev
Retired Dev


Joined: 17 Jan 2003
Posts: 279
Location: Cologne

PostPosted: Wed Mar 17, 2004 6:09 am    Post subject: Reply with quote

I guess, there is still the file /var/run/pbbuttonsd.pid from an older session. Delete it and start pbbuttonsd
_________________
hacking is not a crime
Back to top
View user's profile Send private message
gordin
Guru
Guru


Joined: 11 Oct 2002
Posts: 300
Location: Germany/WI

PostPosted: Wed Mar 17, 2004 10:49 am    Post subject: Reply with quote

Nope, there isn't.
But it seems that the problem has solved itself. After a new reboot it is now working. I have not changed anything, just rebooted.
(I didn't noticed that the battery was low and suddenly it switched off and I had to reboot ;-)
Strange, but it works...
Back to top
View user's profile Send private message
gordin
Guru
Guru


Joined: 11 Oct 2002
Posts: 300
Location: Germany/WI

PostPosted: Wed Mar 17, 2004 3:55 pm    Post subject: Reply with quote

Unfortunately pbbuttonsd does not detect lid-close.
Is there anything special to activate it?
Back to top
View user's profile Send private message
DrACoNuS
Tux's lil' helper
Tux's lil' helper


Joined: 03 Oct 2002
Posts: 116
Location: Edmonton, Alberta, Canada

PostPosted: Wed Mar 17, 2004 5:49 pm    Post subject: Reply with quote

Checkout pmud and search around the forums, there's tons of information available relating to this topic, have fun!
_________________
Is that a huge bandwidth or are you just happy to see me?
Back to top
View user's profile Send private message
pheelay
Tux's lil' helper
Tux's lil' helper


Joined: 06 Nov 2002
Posts: 128
Location: Ireland

PostPosted: Wed Mar 17, 2004 6:44 pm    Post subject: Reply with quote

/etc/init.d/pbbuttonsd zap
might have fixed this also 8)
Back to top
View user's profile Send private message
gordin
Guru
Guru


Joined: 11 Oct 2002
Posts: 300
Location: Germany/WI

PostPosted: Thu Mar 18, 2004 10:08 pm    Post subject: Reply with quote

pmud does not work with 2.6.x kernels...

/etc/init.d/pbbuttonsd zap didn't work.
(Yes, of course the system then thought pbbuttonsd was not running, but still pbbuttonsd thought it was running and brought up the errormessage. Still don't know why, there was no process, no pidfile or something.)

Still, lidclose does not work. I compiled pbbuttonsd by hand with the --with-pmud option with no effect.
Back to top
View user's profile Send private message
btank
n00b
n00b


Joined: 20 Mar 2004
Posts: 8
Location: Kingston, Ont.

PostPosted: Sat Mar 20, 2004 7:41 pm    Post subject: Reply with quote

this pbbuttonsd.conf will detect a lid close. just alter userallowed to reflect your system. Set to 'paranoid' if you don't want user access to the IPC subsystem.

Code:

# [SYSTEM]
userallowed        = "foo" "bar"; user who is allowed to use IPC
autorescan          = no   ; automatic rescan of event devices
CmdTimeout          = 4

# [MODULE POWERSAVE]
onAC_sleep          = yes
onAC_dim            = no
onAC_coversleep     = yes
onAC_Tsleep         = 72000
onAC_Tdim           = 1800
onAC_Thdoff         = 0
onBattery_sleep     = yes
onBattery_dim       = yes
onBattery_coversleep= yes
onBattery_Tsleep    = 3000   ; time in 1/10s
onBattery_Tdim      = 600   ; time in 1/10s
onBattery_Thdoff    = 12   ; time in multiple of 5 second intervals
SleepKey            = 116
SleepKeyDelay       = 0      ; values > 0 may be dangerous, if the power key is used to trigger sleep
BWL_first           = 22   ; first battery warnlevel, time in minutes
BWL_second          = 10   ; second battery warnlevel, time in minutes
BWL_last            = 3      ; last battery warnlevel, time in minutes
Script_BatCritical  = "/sbin/shutdown -h now"
#Script_ProfChanged  = "/etc/apm/pwrctl-wrapper %s %s"
Script_HDSetup      = "/sbin/hdparm -p -S %d /dev/hda"
EmergencyAction     = sleep   ; action, if battery is critically low
HeartbeatBeep       = yes   ; beep, if nothing else showed that the computer lives
CPULoad_sleeplock   = yes
CPULoad_min         = 20   ; value in percent
CPULoad_period      = 20   ; time in seconds
NETLoad_sleeplock   = yes
NETLoad_min         = 4096   ; trafic in Bytes/s
NETLoad_period      = 20   ; time in seconds
NETLoad_device      = "eth0"

# [MODULE DISPLAY]
#LCD_Brightness     = 8      ; initial LCD brightness level
LCD_FadingSpeed     = 5      ; 0 = no smooth fading
LCD_AutoAdjust      = yes   ; only on Aluminum PowerBooks
LCD_IllumUpKey      = 225
LCD_IllumDownKey    = 224
LCD_Threshold       = 94
LCD_AutoAdjMin_Bat  = 2         ; autoadjust parameter
LCD_AutoAdjMax_Bat  = 7
LCD_AutoAdjMin_AC   = 1
LCD_AutoAdjMax_AC   = 15
#KBD_Brightness     = 0      ; initial keyboard illumination level
KBD_FadingSpeed     = 5      ; 0 = no smooth fading
KBD_AutoAdjust      = yes   ; only on Aluminum PowerBooks
KBD_IllumUpKey      = 0
KBD_IllumDownKey    = 0
KBD_IllumOnKey      = 0
KBD_Threshold       = 28   ; only on Aluminum PowerBooks
dev_FrameBuffer     = "/dev/fb0"
UseFBBlank          = yes
DimFullyDark        = no

# [MODULE OSSMIXER]
Volume              = 50   ; initial volume level
Speakers_muted      = no   ; mute after startup?
VolumeUpKey         = 115
VolumeDownKey       = 114
MuteKey             = 113
dev_Mixer           = "/dev/mixer"
MixerInitDelay      = no
MixerChannels       = "volume, speaker"

# [MODULE CDROM]
dev_CDROM           = "/dev/cdrom"
EjectCDKey          = 161
EjectCDKeyDelay     = 0

# [MODULE PMAC]
dev_PMU             = "/dev/pmu"
dev_ADB             = "/dev/adb"
TPModeUpKey         = 225 + alt
TPModeDownKey       = 224 + alt
TPMode              = drag
KBDMode             = fkeysfirst
Back to top
View user's profile Send private message
bzurc51
n00b
n00b


Joined: 03 Feb 2004
Posts: 18

PostPosted: Tue Mar 23, 2004 5:27 pm    Post subject: Reply with quote

gordin wrote:
Nope, there isn't.
But it seems that the problem has solved itself. After a new reboot it is now working. I have not changed anything, just rebooted.
(I didn't noticed that the battery was low and suddenly it switched off and I had to reboot ;-)
Strange, but it works...


Did you ever figure out what the problem was? I just migrated to udev and now I'm having the same issue. Might this be a problem with udev? /dev/pmu does exist so not sure what is going on here.
Back to top
View user's profile Send private message
btank
n00b
n00b


Joined: 20 Mar 2004
Posts: 8
Location: Kingston, Ont.

PostPosted: Tue Mar 23, 2004 6:19 pm    Post subject: Reply with quote

my guess is that the pbbuttonsd daemnon was halted by

/etc/init.d/pbbuttonsd stop

but in actualilty it keeps on truckin. It needs a HUP as per these instructions, from the 'connecting / disconecting new keyboards' of pbbuttonsd man page:

Quote:

l thouth this solution is quite a hack, I implemented it for convenient use. Because of rescanning the event devices often might prevent the hard disk from spin down the rescanning is _not_ done automatically and must be trigered by the user after she/he had connected a keyboard for eg. to the USB Bus. Rescanning is initiated by sending the HUP signal to the server:

kill -HUP ´cat /var/run/pbbuttonsd.pid'


it's only relevant if you consider this: if the aim is to restart the daemon so that it'll scan for new devices, why not /etc/init.d/pbbuttonsd restart?

#cat /etc/init.d/pbbuttonsd | grep kill

will let you know if /etc/init.d/pbuttonsd stop/restart calls a kill -HUP like it should.

I'd do it, but this machine is no longer running gentoo, waiting for sleep to be implemented in 2.6.
Back to top
View user's profile Send private message
bzurc51
n00b
n00b


Joined: 03 Feb 2004
Posts: 18

PostPosted: Tue Mar 23, 2004 10:51 pm    Post subject: Reply with quote

btank wrote:
my guess is that the pbbuttonsd daemnon was halted by

/etc/init.d/pbbuttonsd stop

but in actualilty it keeps on truckin. It needs a HUP as per these instructions, from the 'connecting / disconecting new keyboards' of pbbuttonsd man page:

Quote:

l thouth this solution is quite a hack, I implemented it for convenient use. Because of rescanning the event devices often might prevent the hard disk from spin down the rescanning is _not_ done automatically and must be trigered by the user after she/he had connected a keyboard for eg. to the USB Bus. Rescanning is initiated by sending the HUP signal to the server:

kill -HUP ´cat /var/run/pbbuttonsd.pid'


it's only relevant if you consider this: if the aim is to restart the daemon so that it'll scan for new devices, why not /etc/init.d/pbbuttonsd restart?

#cat /etc/init.d/pbbuttonsd | grep kill

will let you know if /etc/init.d/pbuttonsd stop/restart calls a kill -HUP like it should.

I'd do it, but this machine is no longer running gentoo, waiting for sleep to be implemented in 2.6.


Thanks, but I don't think that's related to my problem. Here is the init script:

Quote:
start() {
ebegin "Starting pbbuttonsd"
/usr/bin/pbbuttonsd -d > /dev/null
eend $?
}

stop() {
ebegin "Stopping pbbuttonsd"
start-stop-daemon --stop --quiet --exec /usr/bin/pbbuttonsd
eend $?
}


No way to "HUP" the process since it never was started. I'm pretty sure it's an issue with moving to udev, maybe something to do with the devices like /dev/pmu or /dev/sound/mixer but commenting those out of the pbbuttonsd.conf doesn't fix it. I cracked open the source code for pbbuttonsd but don't program well enough to see what the problem might be.
Back to top
View user's profile Send private message
gordin
Guru
Guru


Joined: 11 Oct 2002
Posts: 300
Location: Germany/WI

PostPosted: Fri Mar 26, 2004 10:05 am    Post subject: Reply with quote

Hi,
don't know if the problem could be related with udev...

I think it was something with the configfile and instaed of saying, hey your config file is buggy, it just says error server is already running. It's just like in Windows ;-)

Try emerging it again and run pbbuttonsd without changing anything in the configfile. That helped with me. I changed it afterwards and restarted the deamon and it nerver complained again.

@lidclose: this is strange. pbbuttonsd detects lidclose. But not the right way. The display will be set to full brightness if it is compeltetly dimmed when closing the lid...
Back to top
View user's profile Send private message
gordin
Guru
Guru


Joined: 11 Oct 2002
Posts: 300
Location: Germany/WI

PostPosted: Fri Mar 26, 2004 10:36 am    Post subject: lidclose does not work [solved] Reply with quote

*argh*
found the problem with lidclose. The problem was, es ever, between screen and back of the chair!
I use the scrollwheel patch. Therefore I can't use /dev/adb.
And this is needed for lidclose detection.
Back to top
View user's profile Send private message
bzurc51
n00b
n00b


Joined: 03 Feb 2004
Posts: 18

PostPosted: Mon Mar 29, 2004 4:20 pm    Post subject: Reply with quote

The problem appears to be an issue with /dev/adb not being created by udev. I'm sure this is a critical device for pbbuttonsd to be able to find, can this just be created manually with mknod? Is anyone running a pure udev system and able to start pbbuttonsd (does your /dev/adb exist?).
Back to top
View user's profile Send private message
gordin
Guru
Guru


Joined: 11 Oct 2002
Posts: 300
Location: Germany/WI

PostPosted: Wed Mar 31, 2004 10:01 pm    Post subject: Reply with quote

What about /dev/null instead of /dev/adb? That is what I use now...
Back to top
View user's profile Send private message
Heimir Freyr
n00b
n00b


Joined: 09 Mar 2003
Posts: 43
Location: Reykjavík, Iceland

PostPosted: Thu Apr 01, 2004 3:03 pm    Post subject: Reply with quote

I had a similar problem when I tried to run pbbuttonsd wrongly configured to use /dev/cdrom when I wasn't using the cdrom module (batteries in both bays). Commenting out the cdrom section helped.
Back to top
View user's profile Send private message
puggy
Bodhisattva
Bodhisattva


Joined: 28 Feb 2003
Posts: 1992
Location: Oxford, UK

PostPosted: Tue Apr 20, 2004 5:17 pm    Post subject: Reply with quote

This seems to happen if you start pbbuttonsd when for some reason, an instance of it has crashed before. You can tell by looking at the IPC message queue using ipcs and if there is something on it (and you have nothing else using it) and pbbuttonsd is not started, you've got a queue relic. remove it using ipcrm and you should be good to go.

I was having a specific problem with /dev/adb as udev doesn't create it yet as there is no device class in sysfs for it yet. I am not using the gentoo tarball so any mknod I did would be lost on reboot. So I made a simple init script to mknod (and on stop, rm) the node /dev/adb. Then I made the pbbuttonsd init script depend on that one.

Hopefully soon their will be adb support in sysfs, as well as /dev/fb and /dev/fb0 (which are available as a patch at present).

Puggy
_________________
Where there's open source , there's a way.
Back to top
View user's profile Send private message
bzurc51
n00b
n00b


Joined: 03 Feb 2004
Posts: 18

PostPosted: Tue Apr 20, 2004 5:48 pm    Post subject: Reply with quote

In the end, I just /dev/null'd all of the missing devices to get it to start up properly. I think I did this for /dev/adb, /dev/fb0, and one other but everything seems to be working OK. I haven't really done the research to see what side effects this might cause with pbbuttonsd but hopefully we'll have these undev classes defined soon.
Back to top
View user's profile Send private message
puggy
Bodhisattva
Bodhisattva


Joined: 28 Feb 2003
Posts: 1992
Location: Oxford, UK

PostPosted: Tue Apr 20, 2004 5:50 pm    Post subject: Reply with quote

bzurc51 wrote:
In the end, I just /dev/null'd all of the missing devices to get it to start up properly. I think I did this for /dev/adb, /dev/fb0, and one other but everything seems to be working OK. I haven't really done the research to see what side effects this might cause with pbbuttonsd but hopefully we'll have these undev classes defined soon.


It basically means that alot of it won't work. :-)
_________________
Where there's open source , there's a way.
Back to top
View user's profile Send private message
bzurc51
n00b
n00b


Joined: 03 Feb 2004
Posts: 18

PostPosted: Tue Apr 20, 2004 6:04 pm    Post subject: Reply with quote

puggy wrote:
bzurc51 wrote:
In the end, I just /dev/null'd all of the missing devices to get it to start up properly. I think I did this for /dev/adb, /dev/fb0, and one other but everything seems to be working OK. I haven't really done the research to see what side effects this might cause with pbbuttonsd but hopefully we'll have these undev classes defined soon.


It basically means that alot of it won't work. :-)


Yeah, I guess that was a dumb way to say it. Obviously, some things are going to be broken by doing this, but, since funtions like sleep are still broken for my hardware (Albook 1.25), pbbuttons is working for everything I currently need.
Back to top
View user's profile Send private message
puggy
Bodhisattva
Bodhisattva


Joined: 28 Feb 2003
Posts: 1992
Location: Oxford, UK

PostPosted: Wed Apr 21, 2004 12:00 pm    Post subject: Reply with quote

bzurc51 wrote:
puggy wrote:
bzurc51 wrote:
In the end, I just /dev/null'd all of the missing devices to get it to start up properly. I think I did this for /dev/adb, /dev/fb0, and one other but everything seems to be working OK. I haven't really done the research to see what side effects this might cause with pbbuttonsd but hopefully we'll have these undev classes defined soon.


It basically means that alot of it won't work. :-)


Yeah, I guess that was a dumb way to say it. Obviously, some things are going to be broken by doing this, but, since funtions like sleep are still broken for my hardware (Albook 1.25), pbbuttons is working for everything I currently need.


Sleep is under development at the moment.

Puggy
_________________
Where there's open source , there's a way.
Back to top
View user's profile Send private message
puggy
Bodhisattva
Bodhisattva


Joined: 28 Feb 2003
Posts: 1992
Location: Oxford, UK

PostPosted: Wed Apr 21, 2004 5:02 pm    Post subject: Reply with quote

btank wrote:
this pbbuttonsd.conf will detect a lid close. just alter userallowed to reflect your system.


On what kind of machine is that? On my 15" powerbook it just doesn't work. I've tried coversleep on and off and even making sure that pmud support isn't compiled into pbbuttonsd by passing configure flags.

I know it won't sleep, but I'm pretty sure it is mean't to turn the screen off.

Puggy
_________________
Where there's open source , there's a way.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on PPC All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum