Is the new parent always "init" or is there some way to control who gets to be the new parent?
Wikipedia seems indicates that it's always "init". I really hope that this is not the case. I have tried everything I can think of with setpgid and setsid, but no luck. And now that I see this wikipedia article I need advice.
In a Unix-like operating system any
orphaned process will be immediately
adopted by the special init system
process. This operation is called
re-parenting and occurs automatically.
Even though technically the process
has the "init" process as its parent,
it is still called an orphan process
since the process that originally
created it no longer exists.
Taken from wikipedia
The reason I'm asking is because I'm making a Mac app that runs a number of worker processes. I want these worker processes to appear as children of the main process in the process-hierarchy of the task manager. Some of the workers run as different users and on Mac OS X I need to fork twice to pass privileges to the child process. Because I "double fork" the workers currently run as deamons, and when looking with task manager I see the workers are having "init" as their parent process.
Orphaned children are always adopted by init. There is no Unix way of changing the parent to some non-init process.
As of Linux 3.4 this is no longer strictly true. There's still no portable Unix way of doing this but as Andy Lutomirski points out Linux 3.4 adds PR_SET_CHILD_SUBREAPER for prctl.
In effect, a subreaper fulfills the role of init(1) for its
descendant processes.
On Linux, you can use PR_SET_CHILD_SUBREAPER to indicate that your orphaned descendants should be re-parented to you instead of to init.
I think reptyr can perform what you want. Check it out:
https://linux.die.net/man/1/reptyr
https://github.com/nelhage/reptyr
Related
Hi I am facing a strange situation where I am trying to set a set of tasks as complete all concurrently.
The first one goes through and second one goes through sometimes (rarely) but mostly doesnt go through.
When I do these individually they work.
Something to do with database locking I feel. Is there some workaround or code for executing task and variable updates concurrently ?
Do they belong to the same process instance?
And yes, there will be a db locking mechanism in place, because when you complete each task a process instance will need to move forward.
Can you please clarify what are you trying to solve? what is your business scenario?
Cheers
Activiti uses pre-emptive locking and this can cause problems for parallel tasks.
Typically if you use the "exclusive" flag the problems go away (https://www.activiti.org/userguide/#exclusiveJobs).
Keep in mind that jobs never actually run in parallel, the job engine selects jobs to run and if there are multiple they will be run sequentially (which appears to be parallel to the user).
I'm running into serious productivity issues when debugging flows. I can only assume at this point is due to a lack of knowledge on my part; particularly effective debugging techniques of flows. The problems arise when I have one flow which needs to "wait" for a consumption of a specific state. What seems to happen is the waiting flow starts and waits for the consumption of the specified state, but despite implemented as a listening future with an associated call back (at this point I'm simply using getOrThrow on the future returned from 'WhenConsumed'), the flows just hang and I see hundreds of Artemis send/write messages in the console window. If I stop the debug session, delete the node build directory, redeploy the nodes and start again the flows restart and I can return to the point of failure. However if I simply stop and detach the debugger from the node and attempt to run the calling test (calling the flow via RPC), nothing seems to happen. It's almost as if the flow code (probably incorrect at this point) results in the StateMachine/messaging layer becoming stuck in some kind of stateful loop which is only resolved by wiping the node build directories and redeploying. Simply restarting the node results in the flow no longer executing at all. This is a real productivity killer, and so I'm writing this question in the hope and assumption I've missed an obvious trick in how to effectively test/debug flows in such a way which avoids repeatedly re-deploying the nodes.
It would be great if someone could explain how to effectively debug flows; especially flows which are dependent on vault updates and thus wait on a valut update event. I have considered using a subflow, but this would ultimately, (I believe?) not result in quite the functionality required; namely to have a flow triggered when an identified state is consumed by a node. Or maybe it would? Perhaps this issue is due to not using a subFlow??? I look forward to your thoughts anyway!!
Not sure about your specific use case. But in general,
I would do as much unit testing as possible before physically running the nodes and see if the flow works.
Corda provides three levels of unit testing: transaction/ledger DSL, mock network and driver DSL. So if done right, most if not all bugs in the flows should be resolved by the time of runnodes. Actual runnodes mostly just reveal configuration issues.
I am a newbie in the field of OS and trying to learn it by hacking into xv6.My doubt is can we decide before making a call to fork whether to run parent or child using system calls.i,e i can have a function pass an argument to kernel space and decide whether to run parent or child to run first.The argument can be:
1-parent
0-child.
I think the problem is that fork() just creates a copy of the process and makes it runnable, but the module responsible for allowing it to run is the scheduler. Therefore, the parameter you mentioned should also provide this information to the scheduler in some way.
If you manage to do that, I think you can enqueue the two process in the order you prefer in the runnable queue and let the scheduler pick the first runnable process.
However, you cannot control for how long the first process will run. In fact, at the next scheduling event another process might be allowed to run and the previous one would be suspended.
One of the things Marcus Zarra recommends in his Core Data book when talking about setting up an app's core data stack is to put calls to addPersistentStoreWithType:configuration:URL:options:error: on a background thread, because it can take an indeterminate amount of time (e.g., to run migrations). Is there a simple way to tell MagicalRecord to do that? It looks like all of its setupCoreDataStack... methods perform everything on the calling (presumably main) thread.
I don't think it makes sense to just move the top-level setup calls onto a background thread, because it wouldn't be safe to start using MR from the main thread until at least the contexts had been created, right? Do I need to implement my own setupCoreDataStackWithAsyncMigration or somesuch thing?
There is the wwdc2012 example code for setting up iCloud on a background thread (Shared Core Data sample). You could refractor the CoreDataController to use MagicalRecord (and ignore anything iCloud). IIRC the locking mechanism, to stop other threads from accessing the store while the setup is in progress, is already present.
Before you go down that route measure the time needed to startup on the device. If the startup is fast enough for your needs then you might want to stick with the setup on a main thread.
Migrations can take some time but migration won't occur on every app launch. Migration time depends on data volume and complexity of changes between model versions. So again it is a judgment call to invest time to move the migration to a background thread or to keep the user waiting.
I recently learned about the exec() system call in unix. Consider a process executing an exec() and the "transformed process" again executes an exec() and so on. And suddenly the currently executing thing fails, so the context of the previous proc has to be restored.
My question is if the failures keep on occurring in a cascading fashion then would the "original" context still be available. In other words, how much memory can unix spend to go on and saving contexts.
exec() family are replacing system calls - they completely replace the original process with the new one, so there is no turning back. To keep the original context use system() call (which is a wrapper around fork() and exec())