Unable to open /dev/cua/a: Device busy
syn_NOSPAM_uw
I am trying in vain to free my /dev/cua/a port so that I can attach my
APC UPS to it and monitor it with NUT (Network UPS Tools). This system
is a Sun SPARCstation 5 running Solaris 9 and Network UPS Tools version
2. I get the following error when starting the UPS driver:
Unable to open /dev/cua/a: Device busy
I deactivated sac and ttymon also commented out the console port in
/etc/inittab. So I don't know who is still using /dev/cua/a on my
system, here is also an ouput of the full ps:
UID PID PPID C STIME TTY TIME CMD
root 0 0 0 23:01:53 ? 0:01 sched
root 1 0 0 23:01:56 ? 0:00 /etc/init -
root 2 0 0 23:01:56 ? 0:00 pageout
root 3 0 0 23:01:56 ? 0:00 fsflush
root 302 293 0 23:02:47 ? 0:01 /usr/lib/ssh/sshd
root 293 1 0 23:02:25 ? 0:00 /usr/lib/ssh/sshd
root 269 1 0 23:02:22 ? 0:00 /usr/sbin/nscd
root 44 1 0 23:02:06 ? 0:00 /usr/lib/sysevent/syseventd
root 248 1 0 23:02:19 ? 0:00 /usr/sbin/syslogd
root 291 1 0 23:02:24 ? 0:00 /usr/lib/inet/xntpd
smmsp 284 1 0 23:02:23 ? 0:00 /usr/lib/sendmail -Ac -q15m
root 256 1 0 23:02:20 ? 0:00 /usr/sbin/cron
root 283 1 0 23:02:23 ? 0:00 /usr/lib/sendmail -bd -q15m
root 278 1 0 23:02:23 ? 0:00 /usr/lib/utmpd
As you cann see there is nearly nothing... Does anyone know how I can
get my /dev/cua/a free for usage ?
Thanks and Regards
Andrew Gabriel
syn_NOSPAM_uw <syn_NO...@hotmail.com> writes:
> Hello,
>
> I am trying in vain to free my /dev/cua/a port so that I can attach my
> APC UPS to it and monitor it with NUT (Network UPS Tools). This system
> is a Sun SPARCstation 5 running Solaris 9 and Network UPS Tools version
> 2. I get the following error when starting the UPS driver:
>
> Unable to open /dev/cua/a: Device busy
>
> I deactivated sac and ttymon also commented out the console port in
> /etc/inittab. So I don't know who is still using /dev/cua/a on my
> system, here is also an ouput of the full ps:
>
> get my /dev/cua/a free for usage ?
There is a bug (actually a POSIX bug) that can leave the port
permanently wedged if there are characters buffered to be
transmitted but they never will be (e.g. due to flow controlled
off).
This is circumvented in Solaris 10, in that if this situation
arises, the driver will discard the buffered characters after
a timeout if the process that had the port open no longer
exists, so the port can be opened again and reused.
(However, you can't run Solaris 10 on a SPARCstation 5.)
--
Andrew Gabriel
Helmut Kreft
>
> I am trying in vain to free my /dev/cua/a port so that I can attach my
> APC UPS to it and monitor it with NUT (Network UPS Tools). This system
> is a Sun SPARCstation 5 running Solaris 9 and Network UPS Tools version
> 2. I get the following error when starting the UPS driver:
>
> Unable to open /dev/cua/a: Device busy
>
What happened to cua/b? I never converted /dev/cua/a so I'm just guessing
that any of the following might be wrong:
Make shure, the target of the symlink /dev/cua/a actually has proper
permissions set. The default would be 0600 uucp:uucp which is most
likely not what you want unless your ups daemon would run with the
userid uucp. Otherwise Change it to 0660 and add the ups-daemon to
the group uucp in /etc/groups.
The next thing most likely needed is write access to /var/spool/locks
for the ups daemon. Again, the default permission would prevent that.
Change directory permissions to 0775.
Helmut
--
Almost everything in life is easier to get into than out of.
(Agnes' Law)
Thomas Maier-Komor
IIRC, you cannot use /dev/term/a or /dev/cua/a if your system console is
set to ttya. Take a look at the output of eeprom. The relevant fields
are input-device and output-device.
HTH,
Tom
Darren Dunham
> Hello,
> I am trying in vain to free my /dev/cua/a port so that I can attach my
> APC UPS to it and monitor it with NUT (Network UPS Tools). This system
> is a Sun SPARCstation 5 running Solaris 9 and Network UPS Tools version
> 2. I get the following error when starting the UPS driver:
> Unable to open /dev/cua/a: Device busy
I'm assuming you have the system console on kbd/monitor and not serial
port A...
> I deactivated sac and ttymon also commented out the console port in
> /etc/inittab. So I don't know who is still using /dev/cua/a on my
> system, here is also an ouput of the full ps:
There's no reason to deactivate sac or ttymon on a default install.
Neither of them keep the port open unless you've changed things.
The console line in inittab is kind of useful if you ever need to log in
to the box outside of X. Plus, it's only a login shell. It doesn't
affect lots of other things that will probably be shoved at the console.
You need to be using a port that is not the machine's console.
> get my /dev/cua/a free for usage ?
Is the port open? (fuser /dev/cua/a)
Do you have permissions on the port?
--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
hans m42
syn_NOSPAM_uw <syn_NO...@hotmail.com> wrote:
>Hello,
>
>
>Unable to open /dev/cua/a: Device busy
>
is this the same server, as the one with the strange smc-problem ?
best regards
hans
--
syn_NOSPAM_uw
> is this the same server, as the one with the strange smc-problem ?
Hehe no this isn't the same server.
Regards
syn_NOSPAM_uw
> What happened to cua/b? I never converted /dev/cua/a so I'm just guessing
> that any of the following might be wrong:
cua/b is already used by another UPS connected to it and works fine.
> Make shure, the target of the symlink /dev/cua/a actually has proper
> permissions set. The default would be 0600 uucp:uucp which is most
> likely not what you want unless your ups daemon would run with the
> userid uucp. Otherwise Change it to 0660 and add the ups-daemon to
> the group uucp in /etc/groups.
>
> The next thing most likely needed is write access to /var/spool/locks
> for the ups daemon. Again, the default permission would prevent that.
> Change directory permissions to 0775.
This is all ok...
Regards
syn_NOSPAM_uw
> IIRC, you cannot use /dev/term/a or /dev/cua/a if your system console is
> set to ttya. Take a look at the output of eeprom. The relevant fields
> are input-device and output-device.
Here is that ouput:
> eeprom | grep device
output-device=screen
input-device=keyboard
diag-device=net
boot-device=disk0:a disk net
Regards
syn_NOSPAM_uw
> I'm assuming you have the system console on kbd/monitor and not serial
> port A...
I am not sure about that, how do I check this ?
> There's no reason to deactivate sac or ttymon on a default install.
> Neither of them keep the port open unless you've changed things.
Ok I will reactivate it, i wasn't sure.
> Is the port open? (fuser /dev/cua/a)
Fuser returns no PIDs.
> Do you have permissions on the port?
Yes that's all set up correctly.
Regards
Greg Menke
syn_NOSPAM_uw <syn_NO...@hotmail.com> writes:
> Darren Dunham wrote:
>
> > There's no reason to deactivate sac or ttymon on a default install.
> > Neither of them keep the port open unless you've changed things.
>
> Ok I will reactivate it, i wasn't sure.
>
Apologies if this has already been covered, have you removed the port
from the services list as given by "pmadm -l"? I had endless trouble
getting minicom to use a port, which sounds similar to your situation.
Gregm
ML Starkey
syn_NOSPAM_uw wrote On 10/11/05 17:14,:
> Hello,
>
> I am trying in vain to free my /dev/cua/a port so that I can attach my
> APC UPS to it and monitor it with NUT (Network UPS Tools). This system
> is a Sun SPARCstation 5 running Solaris 9 and Network UPS Tools version
> 2. I get the following error when starting the UPS driver:
>
> Unable to open /dev/cua/a: Device busy
This simply means that the serial port is being used by some other
process. Another message that means the same thing is "all ports busy".
(Also, make sure you are using the cable that the APC UPS requires;
probably not what is happening here, as if that were the case, the
message would probably be "no device" or something like that.)
> I deactivated sac and ttymon also commented out the console port in
> /etc/inittab. So I don't know who is still using /dev/cua/a on my
> system, here is also an ouput of the full ps:
sac will respawn, according to it's entry in /etc/inittab, so just
killing it won't help here. Nor is it a typical part of troubleshooting
this problem.
>
> UID PID PPID C STIME TTY TIME CMD
> root 0 0 0 23:01:53 ? 0:01 sched
> root 1 0 0 23:01:56 ? 0:00 /etc/init -
> root 2 0 0 23:01:56 ? 0:00 pageout
> root 3 0 0 23:01:56 ? 0:00 fsflush
> root 302 293 0 23:02:47 ? 0:01 /usr/lib/ssh/sshd
> root 293 1 0 23:02:25 ? 0:00 /usr/lib/ssh/sshd
> root 269 1 0 23:02:22 ? 0:00 /usr/sbin/nscd
> root 44 1 0 23:02:06 ? 0:00 /usr/lib/sysevent/syseventd
> root 248 1 0 23:02:19 ? 0:00 /usr/sbin/syslogd
> root 291 1 0 23:02:24 ? 0:00 /usr/lib/inet/xntpd
> smmsp 284 1 0 23:02:23 ? 0:00 /usr/lib/sendmail -Ac -q15m
> root 256 1 0 23:02:20 ? 0:00 /usr/sbin/cron
> root 283 1 0 23:02:23 ? 0:00 /usr/lib/sendmail -bd -q15m
> root 278 1 0 23:02:23 ? 0:00 /usr/lib/utmpd
>
> As you cann see there is nearly nothing... Does anyone know how I can
> get my /dev/cua/a free for usage ?
Couple things, in order of importance:
1.If there is NO keyboard attached to the system, your console is port
"A" (default Sparc behaviour when booting up w/o a Sun KB attached).
This means that you WILL NOT be able to use ttya for anything else. (Not
recommended to remove your inittab entry for the console)
2.pmadm -l and see if there is a port monitor (login service) running on
the port. If there, remove with: pmadm -r -p zsmon -s ttya
3.ISTR from past experiences with the APC daemon that is tends to
monitor any and all serial ports, not just the ones you ask it to (or
perhaps that's a default behaviour). See #5 below.
4.ps -ef|grep defunct If you have defunct processes in your process
table, they could be from past failed attempts to use or monitor the
serial port and only a reboot will clear them.
5.fuser -u /dev/cua/a fuser -u /dev/ttya
If you get any output from those commands (will show up as numbers
followed by an "o", grep those numbers through your process table and
see what process has them and kill it.
6. Finally, are you certain port a is operable? Have you used it in the
past? A failing or failed serial port will often act in this manner.
HTH!
syn_NOSPAM_uw
> Apologies if this has already been covered, have you removed the port
> from the services list as given by "pmadm -l"? I had endless trouble
> getting minicom to use a port, which sounds similar to your situation.
Yep I already removed it, a pmadm -l gives nothing back anymore.
Regards
syn_NOSPAM_uw
> Couple things, in order of importance:
>
> 1.If there is NO keyboard attached to the system, your console is port
> "A" (default Sparc behaviour when booting up w/o a Sun KB attached).
> This means that you WILL NOT be able to use ttya for anything else. (Not
> recommended to remove your inittab entry for the console)
Aha, I think that's where my problem is, this SPARC hasn't any keyboard
connected to it as it is a used as a server. So if I understand
correclty I should attach a keyboard to it, reboot and then my first
serial port a would be free, right ?
Regards
Greg Andrews
>
>Aha, I think that's where my problem is, this SPARC hasn't any keyboard
>connected to it as it is a used as a server. So if I understand
>correclty I should attach a keyboard to it, reboot and then my first
>serial port a would be free, right ?
>
No you should not. Instead, you should attach your APC to serial port b.
-Greg
--
Do NOT reply via e-mail.
Reply in the newsgroup.
syn_NOSPAM_uw
> No you should not. Instead, you should attach your APC to serial port b.
Hehe well that's a good idea but there is already one APC connected to
serial port b... We have 2 UPSs and need to monitor both. Do I really
need to get an extra serial card then ?
Regards
Darren Dunham
> Darren Dunham wrote:
>> I'm assuming you have the system console on kbd/monitor and not serial
>> port A...
> I am not sure about that, how do I check this ?
Where do boot messages go? Do you have a keyboard plugged in and watch
them on the screen, or is the machine headless?
syn_NOSPAM_uw
> Where do boot messages go? Do you have a keyboard plugged in and watch
> them on the screen, or is the machine headless?
The machine is headless, it's supposed to be a server.
Regards
Darren Dunham
Then as you were later told, the OBP takes over serial port A for the
console. You could plug in a keyboard/monitor to regain the serial port
if you're willing to admin the box that way.
James Carlson
Yes. Or spring for one of those fancy network adapter cards for the
extra APC(s).
--
James Carlson, KISS Network <james.d...@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Greg Andrews
Well, it is up to you. Plugging a keyboard into the server means
you can't administer it on the console remotely anymore. If you
have to shut it down and type commands at the "ok" prompt, you'll
need to be in front of the machine. You won't be able to telnet/ssh
to a terminal server from home (or your office desktop machine) to
access the console anymore. You'll also have to shut the machine
down cleanly, plug the keyboard in while the power is off, and power
it on with the keyboard plugged in. (i.e. downtime is required to
switch the console to the video display and keyboard)
If remotely administering the console is not an important thing
for you (i.e. you're willing to drive to the building where the
server is on those occaisions you need to work on the console),
and the reboot won't cause any trouble for the services that
this machine provides, then it probably would be cheaper and less
hassle for you to move the console to the screen and keyboard.
I have administered servers both ways, and I prefer to have the
console on a serial port. However, you can weigh the benefits
and drawbacks and decide the best course of action for your server.
Until later,
syn_NOSPAM_uw
> Well, it is up to you. Plugging a keyboard into the server means
> you can't administer it on the console remotely anymore. If you
> have to shut it down and type commands at the "ok" prompt, you'll
> need to be in front of the machine. You won't be able to telnet/ssh
> to a terminal server from home (or your office desktop machine) to
> access the console anymore. You'll also have to shut the machine
> down cleanly, plug the keyboard in while the power is off, and power
> it on with the keyboard plugged in. (i.e. downtime is required to
> switch the console to the video display and keyboard)
>
> If remotely administering the console is not an important thing
> for you (i.e. you're willing to drive to the building where the
> server is on those occaisions you need to work on the console),
> and the reboot won't cause any trouble for the services that
> this machine provides, then it probably would be cheaper and less
> hassle for you to move the console to the screen and keyboard.
>
> I have administered servers both ways, and I prefer to have the
> console on a serial port. However, you can weigh the benefits
> and drawbacks and decide the best course of action for your server.
Thanks for that in depth explanation. This server is really an old
SPARCstation5 and is only used with Network UPS Tools to monitor our two
UPSses so I will take the risk of plugging in a keyboard, loose the
console on serial a but get a free port to monitor the 2nd UPS.
Regards