These questions are quite general since they keep coming up for me in different situations. I'm hoping there are some basic principles/standard practices.
The typical requirements:
A program that acts like a "server", running in linux in the
background (and runs almost non-stop. restarting perhaps daily or weekly)
Handles client connections via some socket protocol
Has startup configuration files
Outputs to one or more log files
My questions:
Should I write the program as a "daemon"? What are things I should consider when choosing the daemon vs non-daemon route?
Where in the linux folder hierarchy should the log files and configuration files go? Should I run it out of some user's home directory or a sub-folder in some user's home directory? Or perhaps I should make a new folder i.e. /my_server_abc/ and then run it from there, writing log files to that directory as well?
Thanks
Should I write the program as a "daemon"?
No.
Do not try to daemonize yourself. Use OS provisioned tools to make your application run in background from a startup script, like start-stop-daemon in Debian/Ubuntu. Systemd and upstart can also handle this for you in their startup scripts, as can most init systems these days.
Writing a daemon has some pitfalls you might not expect, and most modern init scripts don't expect you to do send your own process to background - which would complicate their jobs anyway. This allows for example generating reliable .pid files for tracking your application's process id. If you daemonize yourself, your init system has to rely on your application to correctly communicate your process id somehow since you generate new PID's the init system can't track. This complicates things both for them as for you.
Use libdaemon.
Follow the Filesystem Hierarchy Standard.
I know you are thinking c/c++ when asking this question but I think it's more general than that and the logic used when designing is independent of the language used for the implementation.
There is a python enhancement proposal (PEP 3143) that was used to describe the standard daemon process library that has now become part of the language. If you look in this section on correct daemon behavior it describes how a daemon should act. There are also considerations of the differences between a 'service' and a daemon.
I think that should pretty well answer your general questions on daemons and their behavior. Check out W. Richard Stevens' Home Page and you can find info on 'Unix Network Programming', Prentice Hall which has more information specific to c/c++ when coding daemons in a *nix environment and best practice.
You should write a real daemon (fork of to background an release tty). This makes it easy to run the software on system startup is best practice.
For logging you should keep your logs in the default place: /var/log. You may even want to use syslog for logging, as it is the default under linux and you don't need to care about logfile handling.
Related
So I need to simulate Isis2 in ns-3. (I am also to modify Isis2 slightly, wrapping it with some C/C++ code since I need at least a quasi real-time mission-critical behavior)
Since I am far from having any of that implemented it would interesting to know if this is a suitable way of conduct. I need to specifically monitor the performance of the consensus during sporadic wifi (ad hoc) behavior.
Would it make sense to virtualize a machine for each instance of Isis2 and then use the tap bridge( model and analyze the traffic in the ns-3 channel?
(I also am to log the events on each instance; composing the various data into a unified presentation)
You need to start by building an Isis2 application program, and this would have to be done using C/CLI or C++/CLI. C++/CLI will be easier because the match with the Isis2 type system is closer. But as I type these words, I'm trying to remember whether Mono actually supports C++/CLI. If there isn't a Mono compiler for C++/CLI, you might be forced to use C# or IronPython. Basically, you have to work with what the compiler will support.
You'll build this and the library on your mono platform and should test it out, which you can do on any Linux system. Once you have it working, that's the thing you'll experiment with on NS/3. Notice that if you work on Windows, you would be able to use C++/CLI (for sure) and then can just make a Windows VM for NS3. So this would mean working on Windows, but not needing to learn C#.
This is because Isis2 is a library for group communication, multicast, file replication and sharing, DHTs and so forth and to access any particular functionality you need an application program to "drive" it. I wouldn't expect performance issues if you follow the recommendations in the video tutorials and the user manual; even for real-time uses the system is probably both fast enough and steady enough in its behavior.
Then yes, I would take a virtual machine with the needed binaries for Mono (Mono is loaded from DLLs so they need to be available at the right virtual file system locations) and your Isis2 test program and run that within NS3. I haven't tried this but don't see any reason it wouldn't work.
Keep in mind that the default timer settings for timeout and retransmission are very slow and tuned for running on Amazon AWS, inside a data center. So once you have this working, but before simulating your wifi setup, you may want to experiment with tuning the system to be more responsive in that setting. I'm thinking that ISIS_DEFAULTTIMEOUT will probably be way too long for you, and the RTDELAY setting may also be too long for you. Amazon AWS is a peculiar environment and what makes Isis2 stable in AWS might not be ideal in a Wifi setting with very different goals... but all of those parameters can be tuned by just setting the desired values in the Environment, which can be done in bash on the line that launches your test program, or using the bash "Export" command.
I have seen lately a couple of programs that can be launched as daemons (e.g. linphonecsh) but also offer a second invocation method that will exchange information with the running daemon. In the linpohone case, linephonecsh with one set of parms launches the daemon but if invoked with a different set of parms it can query the status of the daemon (call in progress, call duration, hangup, exit, etc.).
So, since I need to write an app that could go either way, app or daemon, I was wonering about how one does this neat trick. I suppose UNIX domain sockets would work as might named interprocess pipes. D-bus perhaps?
And where might one see a good C/C++ example of this?
Any suggestion and alternate approaches are solicited.
You have a few options:
Shared memory
Pipes
UNIX domain sockets.
You should decide which one suits you best, based on the details of your task. I assume you're on Linux, so a chapter from the book "Advanced Linux Programming" on inter-process communication will help. It provides code examples, too.
I am penning down the features that a remote logging
library might need when built from scratch.
I looked up this: http://www.aggsoft.com/serial-data-logger.htm
I wish to know that what differences can be between a
remote logging library and a remote logger software.
Few things that I thought of:
1. The library can be used in C++ programs to log error messages on the fly.
2. The library will require programming knowledge on the end user's part.
3. The software cannot be used "inside" a C++ program, so we won't be able to log the error messages on the fly? Not sure about this one.
I would like to know that besides logging error messages, what are the things for which it makes sense to use the remote logging library? Sharing big files? Anything else than these two things?
Secondly which is better in what way out of a library and a software - in the current case?
As I mentioned in the my comments to your question, I would think that a logging library would provide some sort of an API/SDK, whereas remote software would not. The same would hold true if its sending messages via TCP/UDP or a serial port. The difference between the 2 options would be how much coding you would have to do. That is, how much would you have to reinvent the wheel?
IMHO, nearly all debug environment/tools support redirect the console output the serial port (using print, or other API). It usually not a a task of Application programmer.
There are other methods for "remote logging":
1) syslog, syslog-ng 's remote service
2) save log local, fetch using ftp
I want to create a C++ application that is to run on some Linux platform on a specific laptop computer. I do however not want the users of this laptop to use any other applications/system features than this program - much like the kiosk modes you would find on computers in a typical internet café.
One issue is that the laptop will be booted by the user, and such has to start my software automatically - leaving as little room as possible for the user to intervene with the process. It does not have to be completely secure, but it should be as close as possible.
What would be the best way to accomplish such a thing? Does there exist (free) Linux distributions specifically made for this (if not, I will probably use Arch Linux)? Are there any steps I could/should take in my program, or can I leave it all to the OS? Would creating my own little Linux distribution specifically for this be worth it?
This shouldn't be on stackoverflow but anyway:
Run a plain X session with no window manager, into this plain X session start your program in fullscreen. Done.
I run a small XUL application this way:
X :10 &
sleep 10
DISPLAY=:10 xulrunner ~/zkfoxtemp/application.ini
I would use a minimal live linux distribution - I prefer tinycorelinux but most will do.
using a minimal distribution ensures that the system doesn't have almost any features or programs you didn't plant there, and will make it easy to modify according to your needs
use a window manager as many programs don't behave properly if ran in plain X session (especially if they use pop up windows), but remove all it's menus and shortcuts
prefer booting from a read only media - this will minimize the chances of corruption (accidentally or intentionally)
remove unneeded services and features from the boot and login scripts
I have to program a C/C++ application. I have windows and linux (ubuntu 9.04) in my machine, and can program in both of them (via gcc/code blocks/vim,etc). The problem is that the executable is going to be run in a Unix (not linux) machine (will have access to it in about 20 days).
My Team Leader doesn´t want all of the code to be programmed in linux - unix. So, some of it will have to be developed in windows (and then many prayers will follow so that nothing bad happens).
The best thing i´ve come up with is to program remotely on the server, from windows and linux, so every programmer (only me for the next 2 weeks) is sort of happy.
In windows, I think i´m stuck with putty, but is there any alternative on linux, rather than ssh-vim? .
I read this Remote debugging with Eclipse CDT but it didn´t bring much light on the subject. At least not much hope.
There is another issue. I don´t consider C/C++ to be a portable language. At least for real programs. Sure it compiles, but many issues will arise, even with boost / stl. I haven´t taken a careful look to the code, but still, how wrong a I?
Any tips will be greatly appreciated.
Thanks in advance.
You could ssh w/ xming for a gui ide/editor that is on the remote machine.
If all the code is one the remote machine and compiled there, don't you have to worry about developers trying to work with the same resources? Also might the machine/network not be able to handle multiple ssh connections if you're using xming?
If you can convince your system administrator to install the libraries (an X server is not required), you can use X forwarding with SSH, which will allow you to execute X apps remotely and have them come up on your local server. If you're using Linux locally, you probably have X running already, and if you are using Windows, you can use the Xming server (with a little configuration to get it to accept remote connections). For debugging, if you need a separate shell, just set another instance of SSH going and perform debugging from another process.
As for portability, it depends on what you are trying to do. If all you want is a simple console-based application, you shouldn't run into any major portability concerns. If you are using more complex code, portability depends heavily on two things. The first is the choice of libraries - sure, you can run applications written for Win32 on Linux with Wine or actually compile them with Winelib, but it's not a pleasant experience. If you choose something more portable like Qt or gtkmm, you'll have a much easier time of things. Likewise for filesystem code - using a library like Boost.Filesystem will make things significantly simpler. The second thing that makes a big difference for portability is to follow the documentation. It's hard to stress this enough - many things that you do incorrectly will have varied results on different platforms, especially if you are using libraries that don't do checks (note: I highly recommend checking code against debug standard libraries for this reason). I once spent nearly a weak tracking down a portability bug that arose because someone didn't read the docs and was passing an invalid parameter.
If you want to use remote desktop like facility try VNC www.realvnc.com
or in case its just a remote login Hummingbird, EXceed could help
You might want to check the wingdb visual studio extension.
Not sure if this will help, but take a peek at sshfs. I haven't had a need to use it myself, but I have read others use it to access remote files and directories via ssh and work on the files locally. I presume you could access your remote home directory via sshfs and then use your local tools to work on the source files. I would very interested in knowing if this works out, so please post back if you give it a shot.
I use No Machine NX, which gives you the entire desktop of the remote machine. It also has a Windows client. I work remotely from home on Fridays, so I'm using it right now. You'll have to install it on the remote machine, and then install a client on your Windows or Linux machine.