I’m trying to run a bash script in the background using Laravel. I’m currently using Symfony process to run it. However, there is a timeout and the user won’t be able to navigate the website until the script is done. The script doesn’t output anything. It simply runs other scripts and take the output and insert it into a database.
I have tried appending & at the end of the command as well as dev/null. No matter what I do the user can’t navigate away from the page until the script is done executing. If the user navigates away from the page, the script is stoped.
Regards,
Arron
You should use laravel queues, it is exactly what you want :
https://laravel.com/docs/5.8/queues
The easiest way is with a database, but if you are using it with redis, you can also use Laravel Horizon to monitor them : https://laravel.com/docs/5.8/horizon
Configure supervisord to run your script in the background. Google how to install and setup supervisor.
Until we can implement our new HEAT SM system i am needing to create some workflows to ease our currently manual user administration processes.
I intend to use Powershell to execute the actual tasks but need to use VBS to send an argument to PS from an app.
My main question on this project is, Can an argument be sent to an already running Powershell process?
Example:
We have a PS menu app that we will launch in the AM and leave running all day.
I would love for there to be a way to allow PS to listen for commands/args and take action on them as they come in.
The reason I am wanting to do it this way is because one of the tasks needs to disable exchange features and the script will need to establish a connection a remote PSsession which, in our environment, can take between 10-45 seconds. If i were to invoke the command directly from HEAT (call-logging software) it would lock up while also preventing the tech from moving on to another case until the script terminates.
I have searched all over for similar functionality but i fear that this is not possible with PS.
Any suggestions?
I had already setup a script to follow this recommendation but i was curious to see if there was a more seamless approach
As suggested by one of the comments by #Tony Hinkle
I would have the PS script watch for a file, and then have the VBScript script create a file with the arguments. You would either need to start it on another thread (since the menu is waiting for user input), or just use a separate script that in turn starts another instance of the existing PS script with a param used to specify the needed action
I was wondering what the difference is between the different command-like classes in Laravel 5.1. As far as I can tell Laravel 5.1 has the following available:
Console commands (artisan make:console)
Commands (artisan make:command)
Handlers (artisan make::command --handler)
Jobs (artisan make:job)
I have come straight from 4.2 to 5.1 so I don't know what happened in between 4.2 and 5.1, but I have been told that the middle one (just commands) are basically not really supposed to be used any more - they are in from when queue-able jobs became 'commands' in 5.0, but Laravel since decided against this, and they're just in for compatibility. However, I'm not 100% on this point, so clarification would be appreciated.
My specific use-case is that I want a place to put a self-contained 'runnable' task. For example, something that will remove files older than 5 days from a given directory (but it could do anything).
At first this sounds like a console command - I want to be able to run it from artisan, for a start. But I may also want it on a schedule (great, artisan schedule:run runs console commands). But I may also want to execute it asynchronously from code. Console commands can be run synchronously with Artisan::call(), but for asynchronous, this is (I think) where queues come in, and it suddenly has to be a job.
Okay so we have a job. We can now add it to a queue from code, but how do we execute it as an artisan command (synchronously)? Can I just create a thin console command and add the DispatchesJobs trait (or the code therein) to it, and then dispatch the job? Does the job always have to go on a queue, or can we make a job execute synchronously (and, ideally, output to the console command's output?) The same question goes for running it on a schedule - am I supposed to create this console command and add that to the scheduler, or can I make the scheduler run the job directly?
And finally, we have 'commands' that aren't console commands nor are they jobs. As I said before, people tell me these are just hangers-on from a Laravel 5.0 code change that was (kinda) reverted. But the artisan make command still exists for them, so they can't be that dead. Also, what's the deal with a self handling command (the default, comes with a handle method) and one that 'requires' a handler class (run artisan make:command --handler)? How do you actually make these execute? Manually with (new App\Command\SomeCommand)->handle(); or (new App\handlers\SomeCommandHandler)->handle(new App\Command\SomeCommand), or is there some hidden system I don't know about (maybe they can be dispatched using the job/queue dispatcher)? Also you can create 'queued' commands artisan make::command --queued, so how do these differ, too?
I guess my question boils down to the following:
What is the real (semantic and functional) difference between them all?
What is the correct way to 'run' them?
Which is best for my purposes of a generally-standalone bit of code that needs to be run, in whatever manner I feel appropriate?
I found information in the documentation on how to use queues and create console commands, but nothing on exactly when to use them or really anything on command classes and handlers.
Related but not exactly the same (also, it's unanswered): Laravel 5.1 commands and jobs
Console Commands
Laravel has had console "commands" for some time. They are basically unchanged, and work as they always have. In simple terms, they are the equivalent of routes for the command line - the entry point into the application. They are in no way related to...
The Command Bus
Laravel 5.0 introduced an implementation of the Command Bus pattern - Command Bus Commands. (I believe these were renamed to Jobs because of the resulting confusion between them and CLI Commands).
A command bus as two parts - an object that represents a command to be executed, with any and all data it needs (the job), and a class to execute the command (the handler).
The Handler
In laravel, you can declare a job to be self handling - that is, it has a handle method itself.
If you want to register a command handler, you can call the following in a service provider:
app('Illuminate\Bus\Dispatcher')->maps(['Job' => 'Handler']);
where Job is the class name for the job, and Handler is the class name for the handler.
The handlers directory in laravel 5.0 was a way of implicitly declaring those relationships (ie. EmailCommand in the commands folder would have an EmailCommandHandler in the handlers folder).
Dispatching a Command
You can use the following to dispatch a command.
app('Illuminate\Bus\Dispatcher')->dispatch(new EmailPersonCommand('email#you.com', $otherdata));
Queues
Jobs, by default, will run as soon as they are called (or dispatched). Setting them as ShouldQueue will always pass them to a queue when they are dispatched.
If you want to run them synchronously sometimes, and asynchronously other times, you can call $dispatcher->dispatchToQueue($job) when you want them to be queued. This is all that happens internally when you pass a ShouldQueue job to ->dispatch().
edit: To Queuing (or not)
I've just had a longer look at the dispatcher. The dispatch method checks if the command is a ShouldQueue, and either forwards it to dispatchToQueue or dispatchNow. You can call either of those methods directly instead of dispatch with your command should you wish to override the default behaviour.
So in your case, depending on what the "default" behaviour of your job is (ie. will it normally be queued?) either:
- have it ShouldQueue, and use dispatchNow in the CLI Command.
- don't have it ShouldQueue, and use dispatchToQueue where you call it in your code.
From the sounds of it, i'd do the former.
I see those "objects" like so: (I added some code examples from one of my side projects)
Console
Things I want to execute from the command line (As you mentioned with your example with "Delete Files older than x"). But the thing is, you could extract the business logic of it to a command.
Example: A console command with fires a command to fetch images from Imgur. The Class FetchImages contains the actual business logic of fetching images.
Command
Class which contains the actual logic. You should also be able to call this command from your application with app()->make(Command::class)->handle().
Example: Command mentioned in Example 1. Contains logic which does the actual API calls to Imgur and process returned data.
Jobs
I made this app with Laravel 5.0 so jobs weren't a thing back then. But as I see it, Jobs are like commands but they are queued and can be dispatched. (As you may have seen in those examples, those commands implement your mentioned Interfaces SelfHandling and ShouldBeQueued).
I see myself as an experienced Laravel Developer but those changes in Commands and Jobs are quite difficult to understand.
EDIT:
From the Laravel Docs:
The app/Commands directory has been renamed to app/Jobs. However, you are not required to move all of your commands to the new location, and you may continue using the make:command and handler:command Artisan commands to generate your classes.
Likewise, the app/Handlers directory has been renamed to app/Listeners and now only contains event listeners. However, you are not required to move or rename your existing command and event handlers, and you may continue to use the handler:event command to generate event handlers.
By providing backwards compatibility for the Laravel 5.0 folder structure, you may upgrade your applications to Laravel 5.1 and slowly upgrade your events and commands to their new locations when it is convenient for you or your team.
Just an addition to the actual answers.
Jobs in Laravel >= 5.1 are Commands Bus in Laravel 5.0.
It is only a naming change because of the confusion between Console\Commands (commands run from the console) and The Command Bus (containing Commands) for the Application Tasks.
You should not confound :
Command Bus : used for "encapsulating tasks your application" (from laravel 5.0 doc) which is now renamed a Jobs
Console\Commands : used for "Artisan [...] the command-line interface included with Laravel" (from laravel 5.1 docs) which is unchanged in Laravel since 4.x
Using Codeigniter 2.2.0 for my project. Is $this->input->is_cli_request() validation is necessary for a cron job?
It is recommended to protect your cronjob not to execute when someone type the URL in their browser. However if you don't have any problem running your cronjob invoked by anyone then can avoid this check.
Refer https://ellislab.com/codeigniter/user-guide/general/cli.html for more details.
It recommented to run cron jobs with command line.
There are many reasons for running CodeIgniter from the command-line, but they are not always obvious.
Run your cron-jobs without needing to use wget or curl
Make your cron-jobs inaccessible from being loaded in the URL by checking for $this->input->is_cli_request()
Make interactive "tasks" that can do things like set permissions, prune cache folders, run backups, etc.
Integrate with other applications in other languages. For example, a random C++ script could call one command and run code in your models!
More info read here
But you also can prevent calling from URL in your server.
I have a script that pulls some data from a web service and populates a mysql database. The idea is that this runs every minute, so I added a cron job to execute the script.
However, I would like the ability to occasionally suspend and re-start the job without modifying my crontab.
What is the best practice for achieving this? Or should I not really be using crontab to schedule something that I want to occasionally suspend?
I am considering an implementation where a global variable is set, and checked inside the script. But I thought I would canvas for more apt solutions first. The simpler the better - I am new to both scripting and ruby.
If I were you my script would look at a static switch, like you said with your global variable, but test for a file existence instead of a global variable. This seems clean to me.
Another solution is to have a service not using crontab but calling your script every minute. This service would be like other services in /etc/init.d or (/etc/rc.d depending on your distribution) and have start, stop and restart commands as other services.
These 2 solutions can be mixed:
the service only create or delete the switching file, and the crontab line is always active.
Or your service directly edits the crontab like this, but
I prefer not editing the crontab via a script and the described technique in the article is not atomic (if you change your crontab between the reading and the writting by the script your change is lost).
So at your place I would go for 1.