I am attempting to run an application using tview to show some telemetry. The application runs fine when invoked from the cmdline as normal. When I update my inittab to run the application:
c1:2345:respawn:/usr/sbin/systatus 38400 tty1 linux
That is when I see cannot open /dev/tty, No such device or address, a reference a line number where I am calling tview.Application.Run. The file / device does exist.
Any ideas as to how I might get around this?
I am referencing this:
GoLang - termbox: panic: open /dev/tty: no such device or address
even though I'm NOT using using termbox, the problem is the same. Is it a fair assumption that anything I launch under /etc/inittab is non-interactive? Is there anyway to disable the interactive part in termbox? I don't see any public functions to do such a thing.
This works, but may be a bad idea.
c1:2345:respawn:/usr/sbin/systatus </dev/tty1
In any case, I need to disable the default ctrl+c handler so that this remains running.
Related
I am running Linux kernel 4.14.149 built by Yocto Zeus, and I am running 2019.07 U-boot. At the recommendation of our security team, I am trying to get rid of the Linux console. I am not worried about debugging (once I get this to work anyways); we have other ways of getting the system logs out of the machine, and this will not be done on software development boards. That mechanism is already in place and is tested working. We have an i.MX6 as our core (this is an embedded system), and we have dedicated UART5 to our console on dev boards.
I have tried a few different methods to do this. The first was to disable the framebuffer console kernel config (CONFIG_FRAMEBUFFER_CONSOLE). The primary issue with this approach is that it disabled the splash screen. We have a splash screen that is put up in U-boot (and it is displayed again by Linux), but Linux appears to reset the framebuffer or something when it is booting, resulting in the display flickering and being blank for a bit before our applications start, which was unacceptable (and is the reason we put the splash screen up in both U-boot and Linux).
I also tried just setting "console=" on our command line. This is close to what we want to achieve in that the console doesn't come out the UART anymore, but we see it start to appear on the display on top of the splash screen. I haven't found any way to fix that (I can upload a screenshot if desired).
Just eliminating the console parameter entirely didn't appear to work, it still came out the UART. This is to be expected based on the serial console documentation which says it just uses the first available device.
I have tried commenting out the console initialization in main.c in the Linux source, which exploded rather quickly.
I tried setting to be a netconsole (see Where do you send the kernel console on an embedded system?) but the splash screen still got overwritten, same as the setting it nothing case.
The last thing I have tried was just setting it to a bogus device ("console=ttymxc9" on the Linux command line). While this appears to work (there is no data on the display or the UART) it appears to stall (crash?) partway through bootup and without being able to get the logs (it stalls before our application service runs). I say stall because we have Linux configured for a heartbeat and we do still get proper LED heartbeat behavior. None of the systemd services I added to our build however appear to run (I added one to save the journalctl log file after boot to a file on an external SD card for debugging purposes until I get this working)
At this point, I have run out of ideas on how to get rid of the console while keeping the splash screen intact. What is the proper way to disable the Linux console?
For kernel versions 5.11 and newer:
In the submenu "Character devices" under "Device Drivers" from make menuconfig, there is an option called "Null TTY driver" (CONFIG_NULL_TTY) that you can enable and add console=ttynull to the kernel boot cmdline so that all console output will be simply discarded.
You can also disable CONFIG_VT and CONFIG_UNIX98_PTYS, since you don't need to interact with your program via console at all.
For older kernels (like my 4.14):
You can add this support with the diffs at: https://lore.kernel.org/lkml/20190403131213.GA4246#kroah.com/T/ and then follow the instructions above.
More recent versions of yocto use systemd and a service called getty.target to load the serial port console. Disable by running the following command (once):
systemctl mask getty.target
This answer may not fully fit your question, however, it could serve as a research source for other users, just like me. I use the commands below to temporarily turn the console (ttyS0) on and off.
systemctl stop serial-getty#ttyS0.service
and
systemctl start serial-getty#ttyS0.service
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
I created a simple module that controls wheter a USB supplies power for a device when in host mode or not. When loaded, this module cuts off the power to any device connected until told otherwise.
It is also desired that when booted, the system comes with both my module loaded, and the USB supply cut off. To this end, so far I've tried:
Setting my module as a kernel built-in: had no effect, modules that are loaded later overrun my configuration;
Creating an init.d script: Created the script, and set it up to run on rc5. No luck as well, I run into multiple problems with USB devices (such as usb 2-1: device descriptor read/64, error -110);
I'm running Kernel 3.12 on a custom board, and I've tested that the module works as intended if I load it manually (via modprobe) into the system, after logging in.
Ideally, I want to keep these configurations to be done during boot, without any need of logins and such.
So, my question is: how can I postpone the module loading until the last possible minute, assuring that any other configuration is already finished? Also, is udev a good solution for this sort of thing? From what I read, I had the impression it wouldn't be the best fit...
Regards,
Guilherme
So, I've figured out how to get rid of the errors when using an init.d script. All that is needed is to unbind the devices before loading the module. the following line before the modprobe did the trick for me:
echo "2-1" > /sys/bus/usb/drivers/usb/unbind
Regards,
Guilherme
I'll start off by saying I'm no Linux guru, or even close. I use it to develop embedded applications and it serves my purposes just fine as such.
I have a program which is running (I suppose the correct terminology is "running in a terminal") on a CentOS 6.3 box. For debug and statistics, I have a routine which monitors the keyboard (stdin file) and spits out items as requested by the given key-presses. That all works fine when I'm sitting in front of it.
But I'd like to be able to perform these simple functions: press a key, see some output, remotely. I can SSH into the box and execute commands, but I can't "see" this program.
I have tried searching "communicating with other terminals using ssh" and myriad variations, but I guess I'm not asking this correctly -- the search results are worthless.
What I'd like to be able to do is login to my account and then somehow "see" my program running and type keys and see its output. Is this a stdin/stdout redirection issue?
I apologize in advance if this is painfully obvious and I'm just an idiot, but I'd still like to know how to do it... :)
If you use the linux 'screen' utility, you can re-attach to the original terminal session that you used to start the program. basically you just type screen and then run your program. here is more useful info on screen:
http://www.rackaid.com/resources/linux-screen-tutorial-and-how-to
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.)