I am trying to run my application directly from the linux kernel(without usage of cron or something like that). If I change ./init/init.c, it runs too early:
$ dmesg
...
[ 0.605657] TEST!!!
...
My idea is to launch an application after successful user login, but I can't find an appropriate function to use.
You're jumping to conclusions. Why do you want the kernel to do anything if you have the whole userspace running already? (you want it on user login)
Have a look at one of the standard mechanisms for this (depending on what's available in your system):
systemd user sessions
.profile / .xinit files for users
For advanced scenarios, maybe even socket activation for services.
Related
Is it technically possible to launch a desktop app on Gnome (Fedora or any other RHEL based distro) without being forced to log in first into the user session?
I need to boot a desktop software on system start even if there is no user to log in at that moment. Setting the account to automatically log in is of course an option but highly insecure to leave a system in that state.
You may be able to run the software in the session that runs GDM. However, I'd suggest considering some alternatives.
What about running a VNC session (Fedora includes tigervnc), and running the app inside that? You could set up some dummy user account to do this, and have this happen automatically through either a systemd unit or maybe an #reboot crontab entry.
I'd like to trigger file system events on a Linux virtual machine (VirtualBox). I'm not sure how to approach this, but I can imagine there could be 2 ways of doing it:
with a built-in command in the guest system
or from the host system controlling the guest through VirtualBox commands
I did some research and found tools like guard/listen, but I could not manage to make them work. (Guard asking for plugins and the documentation is not clear to me...)
My goal is not a new thing, I'd like to forward file system events from the host to the guest. On the host side I'm using fswatch to hook up to file system events. Fswatch would run a script on the guest system via SSH - that script/command could trigger an fs event in the guest system based on the parameter from fswatch which was a path... It's not an efficient approach I guess but for development purposes when I modify some files in the IDE should be good enough.
This one solved my problem: vagrant-notify-forwarder
How can I edit my startup scripts in linux so that I get to the login screen as soon as possible? I want all the other accessories (such as Bluetooth, Wifi, Ethernet) drivers to run ONCE I have gotten to the login screen and can now log into shell.
The only thing I can think of is to change the rmnologin order so that it runs before anything else. Is that a good idea?
Use a dependency based init tool like systemd or startpar, then if you still don't have prompt fast enugh dependency reasearch (or trial and error) would be in order. Also set your bios to fast boot. You can also boot into single user mode then change run level later if you want.
I was wondering if i can run a exe with daemons in mac and linux or do you have any other solutions to do something similar to a windows service that is a scheduler ? I know i can use crontab but i was wondering if there was other way to do it.
Thx
On OS X, the preferred way of doing things like this is with launchd daemons. You create a .plist file with information about what program to run, parameters to pass it, and what conditions to start it under (i.e. at certain times, when a network connection is received on a certain port, or just run always), and various other options. Lingon provides a handy GUI for creating the .plist, or just read the Apple LAUNCHD docs and create it yourself. Put the .plist in /Library/LaunchDaemons, and either reboot or activate it with sudo launchctl load /Library/LaunchDaemons/whatever.plist.
A warning about using launchd: most daemon-type programs for unix will "daemonize" themselves -- they drop into the background, and generally detach themselves from the program that started them. Launchd doesn't like this. It wants to keep watch over its children, so that it can monitor their status, relaunch them if necessary, etc. So you may either need to tell the program not to daemonize, or add an option to the .plist to tell launchd not to freak out if the program appears to quit.
Linux alternative to windows NT services are daemons. You can read a little more about it
here.
You also start executables by scripts located in "/etc/init.d" Just look at one of those scripts for reference. If you want to make a task or executable start at a given time use a crontab. It is made for this purpose and I don't see why use something else.
If you have a mono executable probably the easiest way is just to make a script in "init.d" if you want to start when system starts or make a crontab entry. It is realy easy. Here you can find a simple reference.
I have written a daemon in linux for doing dhcp for an embedded system. This platform only has a linux kernel running on it and have no CLI support. What is the best way for me to test my daemon? How do I write a program that will call the main function in this daemon and verify if its working fine?
Appreciate the answers.
When I've been in a situation like this, I've written a second daemon (or had a second listener in the existing daemon) to take the place of a CLI, listening at a particular port and responding to a very limited command set of your own choosing.
In this case, all you really care about is triggering the function on demand, so you could even have it trigger when you connect to this second port, and then report results back to the socket.
I strongly recommend, by the way, making sure your embedded system has some more generic mechanism for logging information to persistent storage and retrieving that log. It doesn't have to be syslog or anything so complicated. But you will want that ability in the future to enable forensic analysis of problems in the field.
You will want to write and debug your daemon in a full featured environment first, then install it on the embedded system at the end when you are sure it works properly.
If you can build a dhcp server for the embedded system you can surely build a simple shell for it also. Try building BusyBox or ash or dash.
You could also try using GDB remote debugging. I found an article about it.