The following is my rules file in /etc/udev/rules.d/10-autodvd.rules
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_MEDIA_DVD}=="1", ACTION=="change", RUN+="/usr/local/bin/makemkv.sh sr0"
SUBSYSTEM=="block", KERNEL=="sr1", ENV{ID_CDROM_MEDIA_DVD}=="1", ACTION=="change", RUN+="/usr/local/bin/makemkv.sh sr1"
SUBSYSTEM=="block", KERNEL=="sr2", ENV{ID_CDROM_MEDIA_DVD}=="1", ACTION=="change", RUN+="/usr/local/bin/makemkv.sh sr2"
SUBSYSTEM=="block", KERNEL=="sr3", ENV{ID_CDROM_MEDIA_DVD}=="1", ACTION=="change", RUN+="/usr/local/bin/makemkv.sh sr3"
SUBSYSTEM=="block", KERNEL=="sr4", ENV{ID_CDROM_MEDIA_DVD}=="1", ACTION=="change", RUN+="/usr/local/bin/makemkv.sh sr4"
It seems to be really hit or miss on actually running the scripts, is there a better way to do this?
Udev sorts the rules files lexically, and at the time your rules are applied, the ID_CDROM_MEDIA_DVD variable probably isn't set yet. This is the case on a default install of systemd udev. The ID_CDROM* variables are set in 60-cdrom_id.rules, so you should rename your rules file to sort after this.
Note that you're not supposed to start a long running program with the RUN+= key.
RUN{type}
[...]
This can only be used for very short-running
foreground tasks. Running an event process for
a long period of time may block all further
events for this or a dependent device.
Starting daemons or other long-running
processes is not appropriate for udev; the
forked processes, detached or not, will be
unconditionally killed after the event handling
has finished.
Your rules may be written as one rule:
SUBSYSTEM=="block", KERNEL=="sr[0-4]", ENV{ID_CDROM_MEDIA_DVD}=="1", ACTION=="change", RUN+="/usr/local/bin/makemkv.sh %k"
Related
I have added new tasks to my DAG and it needs to backfill them. At the moment, when I run airflow backfill it runs all the tasks(new ones and the old ones) and I would like to ignore the old tasks which have already succeeded.
Is there any way to skip the tasks with success state in a backfill?
As of Airflow version 1.8.1, successful tasks should not be scheduled by a backfill, see AIRFLOW-1124.
Note that you can also specify which tasks you want to run in a backfill:
-t TASK_REGEX, --task_regex TASK_REGEX
The regex to filter specific task_ids to backfill
(optional)
The ignore dependencies flag may also help you in case your new tasks depend on any old ones that may not have succeeded.
-i, --ignore_dependencies
Skip upstream tasks, run only the tasks matching the
regexp. Only works in conjunction with task_regex
How can I verify if my code on vim (Unix) has syntax errors?
Is there any command to test the code?
Thank you in advance!
Use a plugin which checks your code.
The one I use, and I'm not alone, is syntactic: https://github.com/vim-syntastic/syntastic
This works for a tons of different languages and even has multiple "lint" engines to choose from for each language. For instance, I use python and can configure syntactic to use one of the following checkers: flake8, pyflakes, pylint and the native python checker. And, yes, it checks vim script as well.
If you can't use any plugins AND only want to debug your vim-scripts, then your best bet is to use vim's own debugger (help debug-scripts). To use this mode:
Start vim in debug mode: vim -D my_broken_script.vim
use :debug to switch into debug mode.
use Ex commands to inspect local variables, echo idx, or global ones: echo g:idx, where idx is the var.
set breakpoints with :breakadd on either functions or files. And delete them with :breakdel
Use profile to investigate performance issues (help :profile): :profile start func and :profile stop
I'd like start grunt with an option set with multiple vales. Is this possible?
i.e.
grunt doThis --ip 1.2.3.4 --ip 2.3.4.5
Is this possible?
grunt.registerTask('doThis', function () {
console.log(grunt.option('ip'));
});
grunt doThis --ip="192.168.1.1" --ip="192.169.1.10"
Running "doThis" task
192.169.1.10
Done, without errors.
Yes. Grunt uses nopt to parse the command line options and it supports multiple values. You'd pass them like this:
grunt doThis --ip=1.2.3.4 --ip=2.3.4.5
You'll need at least version v1.0.0-rc1 of Grunt for this to work.
I am writing a build process for a WordPress installation using Ansible. It doesn't have a application-level build system at the moment, and I've chosen Ansible so that it can cleanly integrate with server build scripts, so I can bring up a working server at the touch of a button.
Most of my WordPress plugins are being installed with the unarchive feature, pointing to versioned plugin builds on the official wordpress.org installation server. I've encountered a problem with just one of these, which is that it is always being marked as "changed" even though the files are exactly the same.
Having examined the state of ls -Rl before and after, I noticed that this plugin (WordPress HTTPS) is the only one to use internal sub-directories, and upon each decompression, the modification time of folders is getting bumped.
It may be useful to know that this is a project build script, with a connection of local. I guess therefore that means that SSH is not being used.
Here is a snippet of my playbook:
- name: Install the W3 Total Cache plugin
unarchive: >
src=https://downloads.wordpress.org/plugin/w3-total-cache.0.9.4.1.zip
dest=wp-content/plugins
copy=no
- name: Install the WP DB Manager plugin
unarchive: >
src=https://downloads.wordpress.org/plugin/wp-dbmanager.2.78.1.zip
dest=wp-content/plugins
copy=no
# #todo Since this has internal sub-folders, need to work out
# how to preserve timestamps of the original folders rather than
# re-writing them, which forces Ansible to record a change of
# server state.
- name: Install the WordPress HTTPS plugin
unarchive: >
src=https://downloads.wordpress.org/plugin/wordpress-https.3.3.6.zip
dest=wp-content/plugins
copy=no
One hacky way of fixing this is to use ls -R before and after, using options to include file sizes but not timestamps, and then md5sum that output. I could then mark it as changed if there is a change in checksum. It'd work but it's not very elegant (and I'd want to do that for all plugins, for consistency).
Another approach is to abandon the task if a plugin file already exists, but that would cause problems when I bump the plugin version number to the latest copy.
Thus, ideally, I am looking for a switch to present to unarchive to say that I want the folder modification times from the zip file, not from playbook runtime. Is it possible?
Update: a commenter asked if the file contents could have changed in any way. To determine whether they have, I wrote this script, which creates a checksum for (1) all file contents and (2) all file/directory timestamps:
#!/bin/bash
# Save pwd and then change dir to root location
STARTDIR=`pwd`
cd `dirname $0`/../..
# Clear collation file
echo > /tmp/wp-checksum
# List all files recursively
find wp-content/plugins/wordpress-https/ -type f | while read file
do
#echo $file
cat $file >> /tmp/wp-checksum
done
# Get checksum of file contents
sha1sum /tmp/wp-checksum
# Get checksum of file sizes
ls -Rl wp-content/plugins/wordpress-https/ | sha1sum
# Go back to original dir
cd $STARTDIR
I ran this as part of my playbook (running it in isolation using tags) and received this:
PLAY [Set this playbook to run locally] ****************************************
TASK [setup] *******************************************************************
ok: [localhost]
TASK [jonblog : Run checksum command] ******************************************
changed: [localhost]
TASK [jonblog : debug] *********************************************************
ok: [localhost] => {
"checksum_before.stdout_lines": [
"374fadc4df1578f78fd60b1be6758477c2c533fa /tmp/wp-checksum",
"10d66f7bdbbdd3af531d1b11a3db3059a5868838 -"
]
}
TASK [jonblog : Install the WordPress HTTPS plugin] ***************
changed: [localhost]
TASK [jonblog : Run checksum command] ******************************************
changed: [localhost]
TASK [jonblog : debug] *********************************************************
ok: [localhost] => {
"checksum_after.stdout_lines": [
"374fadc4df1578f78fd60b1be6758477c2c533fa /tmp/wp-checksum",
"719c9da94b525e723b1abe188ee9f5bbaf121f3f -"
]
}
PLAY RECAP *********************************************************************
localhost : ok=6 changed=3 unreachable=0 failed=0
The debug lines reflect the checksum hash of the contents of the files (this is identical) and then the checksum hash of ls -Rl of the file structure (this has changed). This is in keeping with my prior manual finding that directory checksums are changing.
So, what can I do next to track down why folder modification times are incorrectly flagging this operation as changed?
Rather than overwriting all files each time and find a way to keep the same modification datetime, you may want to use the creates option of the unarchive module.
As you maybe already know, this tells Ansible that a specific file/folder will be created as a result of the task. Thus, next time the task will not be run again if that file/folder already exists.
See http://docs.ansible.com/ansible/unarchive_module.html#options
My solution is to modify the checksum script and to make that a permanent feature of the Ansible process. It feels a bit hacky to do my own checksumming, when Ansible should do it for me, but it works.
New answers that explain that I am doing something wrong, or that a new version of Ansible fixes the problem, would be most welcome.
If I get a moment, I will raise this as a possible bug with the Ansible team. However I do sometimes wonder about the effort/reward ratio when raising bugs on a busy tracker - I already have one item outstanding, it has been waiting a while, and I've chosen to work around that too.
Update (18 months later)
This Ansible build system never made it into live. It felt like I was always working around something. Recently, when I decided I needed to move my blog to another server, I finally Dockerised it. This took several weeks (since there is a surprising amount of things to think about in a real WordPress installation) but in general I found the process much nicer than using orchestration tools.
I want to write a grunt task, which will start a server, and run some tests based on that server:
grunt.initConfig({
shell: {
sbtRun: {
options: {
stdout: true
},
command: './sbt run'
}
}
});
grunt.loadNpmTasks('grunt-shell');
grunt.registerTask('run-test-only', ...);
grunt.registerTask('start-server-and-test', ['shell:sbtRun', 'run-test-only']);
But the problem is, the task ./sbt run is not running in daemon. When I run:
grunt start-server-and-test
It will blocking in the shell:sbtRun task forever.
Is there any way to start it in a child process? So the second task run-test-only will be called, and the server will be destroyed automatically after testing?
I was facing a similar issue. I wanted to connect to a database and store the result of a query in a .csv. I created a separate file to do all that work and I was successful in running that file through the command line using:
node filename.js
I used grunt-shell and grunt-exec to run this command but everytime I saw the same error:
const child = require('child_process').exec;
Then, I found another grunt plugin i.e grunt-execute which was able to create a child process and the task was completed successfully. You could find more about grunt-execute here, https://www.npmjs.com/package/grunt-execute.
Hope this helps.