I'm currently working on an automation script that connects users via telnet to different ports (for different command interpreters) on an embedded system. Since the amount of available memory is pretty low on the system, the number of telnet sessions is limited. If a user doesn't close the telnet session normally, the server-side session will just hang and use up an available telnet session. Is there a way in tcl/expect to send commands/execute a procedure before an xterm window closes?
I did some googling, at it turns out expect supports the trap command which allows to run a script when a certain Unix signal is sent to the process hosting the interpreter.
It appears you have to trap SIGHUP but may be you'll also need to trap SIGTERM and/or SIGQUIT. man 7 signal — if on a Linux-based OS — for more info (on a different OS flavor the manual page section may be different).
Related
This question sounds very stupid to me, but if this is somehow possible it would be really helpful.
My application is crashing and I need to debug it. And I run this application in another computer, via SSH (it's an HTTP server). If I could leave a terminal running the application over GDB and SSH all the time, I'd be able to find the bugs. But I don't have a free computer to do that. What can I do? Is there a way to start GDB with nohup(1) plus &> and stuff like that, so I can see GDB output (where command, for example) later?
A classical Unix program called screen is your friend (or its competitor tmux). It allows to keep a virtual console open across multiple logins:
screen
starts such a session; using you can detach from that; using
screen -r
you can reconnect to it later.
However, you don't even need that; just make your program leave a core dump when it crashes; ulimit -c unlimited says "every program that crashes leaves a core dump"; you can then just open the core dump using gdb later on, and everything will be as if you ran the program inside gdb when it crashed.
gdb core.123456
For capturing ssh sessions I use "script" command: "script -c 'ssh user#host' outfile". But I have no idea how to capture sessions to remote hosts, that connected over com(serial) port.
screen script -c 'screen /dev/ttyS0 57600' file
ends immediately with empty log. Both 2 functions that implemented in screen is necessary: ability to switch between opened sessions and ability to perform i/o to /dev/ttyS. I started develop some tiny utility to redirect stdin/stdout to /dev/ttyS but now it's so buggy and doesn't work yet.
First off, a terminal program, like minicom (or good-ol cu), as suggested by Laszlo, is needed to communicate with the remote system. Once you can get such a program to work, then screen can be brought into the picture. Note that this also requires a getty running on the remote computer's serial port. If it's an old-fashioned serial port, you may also need a special null-modem cable.
Screen can be used with such a connection to be able to move access of the session across terminals. However, it cannot be used to spawn more than one session with the remote server. That's because the program running on the serial port (getty) only supports a single session. In this case, the screen runs on the local machine, and the terminal-program session running within screen connects to the remote server. So, it is possible to have multiple screens, but just not more than one connected to the remote server over a single serial port.
With all of that said, serial ports can be used to network two machines, assuming both support the same serial-line networking protocol. Networking eliminates these restrictions.
To open an interactive terminal session to a COM port (/dev/ttyS*), you probably want to use a terminal emulator software, like 'minicom'.
We have about 40 computers running identical hardware and software. They all run Ubuntu 11.10. They all have just one user account to log in. The .profile file is set up to launch a daemon process. The code for the daemon is written in C.
Once in a few weeks, we get a report that the daemon is no longer running. This does not happen on all computers but just one or two. We cannot reproduce the problem consistently.
Looking at the code, the application quits when it receives either SIGHUP or SIGTERM.
As I understand, SIGHUP is generated when a user logs off. In our case, the user never logs off. I am wondering if it is possible that SIGHUP could have been generated for some other reason. Any other thought would be appreciated.
Well, there are a couple of things to note about SIGHUP. Firstly, its origin is from the concept of a hang-up, i.e. loss of connection to a console over something like a modem. In modern parlance this generally means it has lost its controlling tty. Unless you've taken care to detach from your tty, any program started in a given terminal will receive a SIGHUP when the terminal is closed. See here for details on how to do this in your program. Other options include:
running your program inside screen or tmux
run your program with nohup or some other daemonising framework
The other possibility is something is deliberately sending your process a SIGHUP which by "tradition" is often used to signal a process that it should re-read its configuration.
Signals can be sent using kill utility or kill syscall.
Of course, you can try and find out who is sending that signal or disconnecting your terminals or network connections, but there is simpler practical way to fix your problem.
When code is supposed to run as a daemon, but really isn't (just like yours), there is a wrapper that can turn any program into daemon. Surprise - this wrapper is called daemon! It has lots of options, probably most importantly for you, option to automatically restart your utility should it ever die for any reason.
If this command is not installed on your Ubuntu, just sudo apt-get install daemon, and man daemon to get started.
I am having some problems with launching firefox from a Linux daemon written in C.
When I launch firefox on the machine itself (via terminal) from the command shell using /usr/bin/firefox it works OK and a firefox browser window lanunches as it should.
However if I try this within my C daemon using system("/usr/bin/firefox"), firefox launches its process in the terminal but the browser window is not opened?
A similar thing happens when I try to do this using remote terminal acces. It's something to do with telling the system to open firefox in window mode rather than trying to open it in terminal mode - but I dont know how to specify this using bash commands?
I am using Lubuntu 11.10 in my Linux System.
Any help is most appreciated.
There's a reason I asked why you're attempting to do what you want. I didn't want to get into great details in my comment.
Firefox on Unix is an X-Window process (most of the Linux/Unix desktops are based upon the X11 protocol which is the heart of X-Window). What X-Window does is separate the display of the program from the process running the program. For example, I am now running Firefox from a Linux box at work, but the Linux box is actually displaying the Firefox browser window at home on my Mac.
In order to do this, I had to:
Run X11 on my Mac. The X11 program creates a default X11 client display called 0.0 which pretty much says the first screen and the first instance of X11 running (computer geeks like counting from zero). The process runs in the background on my Mac. In a certain sense, it's really a server process and not a client because it's waiting on port 6000 for a client X11 process (Firefox) to tell it what to do.
Before I run firefox, I have to tell my Mac's X11 process that I grant the X11 server running Firefox to be able to display on my X11 client process. Otherwise, you can imagine someone spamming another person by continuously popping up Windows on their display. You can use the xhost program to do this.
In order to run Firefox on the Linux box, I have tell the Firefox process what X11 client I'm running it on. I can do this by setting the DISPLAY environment variable to something like "10.0.1.33:0.0". This means the X11 client is running the the machine on IP address 10.0.1.33, and I want you to use the first screen, and the first instance of the X11 client on that screen.
Now, I can run Firefox on my Linux box, and the display will display on my Mac.
The problem you're running into is that there's simply no X11 client when you're starting FireFox as a daemon process. An X11 client is associated with a user and a display of some sort. The display could be a virtual display, but there's got to be an X11 client that's running and is addressable in some way, so the process knows where to display the output.
By the way, you said daemon which has a very, very specific meaning in Unix/Linux. A daemon is a process that runs in the background and usually has a service (and a port) associated with it. For example, there's an FTP daemon called ftpd, the mail server uses the sendmail daemon, ssh has the sshd daemon. Daemons have no display associated with them.
However, it looks like you might be using the word to mean launching Firefox via another process. Is that true? If so, you'll have to make sure that Firefox knows the X11 display to use (there's a command line setting to use to specify the display), and that your X11 client (your login session) has given permission for another process to update your display with the program window.
Can you please explain what you're trying to do in a bit more detail? If you simply want to download a file from a remote http server (which of course is running the http daemon process called httpd), you should use curl or wget which don't require a display and are way simpler to use. If you're trying to do something else, let us know exactly what it is.
Firefox needs to know which display it should open on. When you run it from within a gui, even through a terminal emulator, the DISPLAY environment variable is set to the appropriate value. When you launch from the daemon, try system("/usr/bin/firefox -display=:0").
Make sure that the DISPLAY environment variable is properly set in your daemon to refer to the X server that you want your firefox to use.
If the daemon is run as a different user account than the user account that "owns" the X server that you want to use, you will also need to use xauth(1) to configure the authentication token to grant permission to use the X server.
Often times, it is far easier to use ssh -X to tunnel X and properly configure the xauth(1) tokens in one go than try to manage xauth(1) tokens yourself. Maybe adding ssh -X into your environment would be suitable, maybe not. (I've even used ssh -X root#localhost before when I needed to run an X client as root and didn't want to bother with configuring xauth(1) manually. ssh(1) is just so much easier.)
I am a business programmer with a few years of Linux administration experience. I'm starting out in embedded Linux. Yesterday, we were discussing a new device design and I was asked a few questions I had no answers for.
The engineers want to have some push buttons on an electronic board with a serial port on it. The OS is Linux.
Normally, when a user will connect to the serial port, a protocol will answer him instead of a Linux login prompt. However, if he pushes a sequence of buttons on the device, a Linux prompt will answer him on the serial port instead.
The Linux driver to handle the push button interrupt handling aside, how can you switch the basic use of the serial port like that? Does anyone have a URL reference on how to do this? (preferably with some sample code)
Note: I proposed providing a nice menu on login for a given user, but no can do.
Thanks in advice for any suggestions.
Best regards,
Bert
The main problem is that the process that implements your device protocol is probably keeping the serial port open.
In this case you should probably:
Wait for the button event
Have the protocol process close the serial port - terminating that process completely might also do for you
Launch a *getty process - or whatever your embedded target uses to present a login prompt on the serial port
Restore the protocol process once you are done
EDIT:
In the steps above I assume the more common case where the process that controls the serial port (e.g. pppd) is not able to act as a getty substitute to provide a login prompt. It is also typically not the same process that provides telnet/SSH/whatever logins.
That said, it's quite possible on a customised embedded Linux system for a process to do more than one thing. In that case you have to configure or modify that process to switch operational modes when appropriate.
Without more information about your embedded target it's impossible to provide a more specific answer.
The getty process is usually started on serial ports to provide a login prompt by /sbin/init, which is configured in /etc/inittab.
init has the concept of "runlevels". Each runlevel defines a separate set of processes that init will keep running. One elegant way to implement this would be to design your "protocol" process so that it is started by init, in the same way as getty. You can then tell init to run your process in some runlevels, and getty in others, and have the pushbutton switch between runlevels. For example, your /etc/inittab might include:
T0:2:respawn:/sbin/getty -L ttyS0 9600 vt100
P0:345:respawn:/sbin/protocol ttyS0 9600
This will run your protocol command on the first serial port in runlevels 3, 4 and 5; but getty in runlevel 2.