Stop the Deployment Solution Agent in Linux Automation
There may be times when you want to test a command or script on the Linux Automation image but don't want to go through all of the hassle of creating a new job, running said job, making a fix, running the job again, etc.
The best way to do testing for scripts/commands is to kill off the agent after it starts. This is a relatively easy task but requires a little bit of speed and quick thinking.
The process is simple. Boot into your Linux automation image (PXE, USB, Cdrom, etc) and wait until you see this prompt
/#
This means you have the ability to type in commands. The "/" is the current working directory and the "#" means you are root. Quickly type in this command
ps ux | grep altiris
The first part of this command shows all running processes on the machine. The "|", or the pipe, sends the output of the first command (ps ux) to the next command. In this case the next command is "grep". Grep searches through text line-by-line with a given pattern. We set the pattern to "altiris" so grep returns every line that has the word altiris in it.
You'll get some output that looks like this
root 2624 0.0 0.0 1580 368 ? S 14:31 0:00 /opt/altiris/deployment/adlagent/bin/adlagent -nodaemon root 2649 0.0 0.0 1564 260 ? S 14:31 0:00 /opt/altiris/deployment/adlagent/bin/adl_automation -watchdog
Now what we're interested in is the numbers in the 2nd column, in this case the numbers are 2624 and 2649. These numbers are the pids, or the Process IDs, of the running process. With those numbers, we can use the "kill" command to stop those processes. For this example, I would run...
kill 2624 2649
This would stop both of the programs which would allow us to use the environment to our hearts desire. Now if for whatever reason we want to restart the agent, we can simply type this command.
source /etc/rc.agent
This should start the agent back up again.

Wouldn't it be easier...
Wouldn't it be easier to just issue a wait job from the DS console?
I created a job called "Wait" and added a "Wait" task. Just choose the correct automation preboot environment and voila, it will sit at the linux prompt.
If you just wanted to test
If you just wanted to test commands then yes running the Wait task is MUCH easier. The one nice advantage to this solution though is that you can restart the agent from the command line and continue on with whatever you were doing. Admittedly, there is still probably a way to do this from the console.
When I originally started working with the Linux automation stuff I wasn't allowed into the console because I'm a student (I work on campus) so to test all of the scripting and I had to kill the agent before it would check-in and reboot. That is where this solution started from. It's also convenient when you start a task and forget to do something before that task runs and need to stop it.
Understood
I understand the reasoning and your scenario and don't argue that you may not have had any other way.
I was only pointing out that once you have access to the console and have the "Wait" job created, it's more convenient and easy to just assign the job instead of being "lightning fast" to kill the process. You can even use the DSWeb console in a pinch.
Kill the computer account
When I was testing a lot of scripts, I made sure that there was no entry in the eXpress DB for the test computer I was playing with before booting to Linux automation. Wait for it to finish booting and say that it's waiting for the DS, then tap Enter and you're at a shell prompt.
The downside to this is before you reboot the machine, you need to delete the machine out of the database or it will just reboot once everything loads up again on that next boot into automation.
More Helpful then previously thought
At first I thought the wait command was the best way but if PXE is having problems this can be very helpful. I am trying to test a few things on a remote pxe server that is having problems connecting to the DS. I couldn't use a wait command because it would restart before it even connected to the DS. So thanks a ton for this!
Would you like to reply?
Login or Register to post your comment.