Matt Bradley is a small-time freelancer who writes the useful stuff down so that everyone can benefit from his experience for free – although small donations of gratitude are accepted (PayPal or Crypto).
With the recent announcement that Dropbox is dropping its support for linux filesystems (other than ext4) in November, you’ll no doubt be searching for an alternative cloud storage provider that supports linux file system synchronisation.
Using filezilla, rename the old wp-includes and wp-admin directories on your web host.
Using filezilla, upload the new wp-includes and wp-admin directories to your web host, in place of the previously renamed directories.
Upload the individual files from the new wp-content folder to your existing wp-content folder, overwriting existing files. Do NOT delete your existing wp-content folder. Do NOT delete any files or folders in your existing wp-content directory (except for the one being overwritten by new files).
Upload all new loose files from the root directory of the new version to your existing wordpress root directory.
Reconnect to admin page. If a database update is required it’ll automatically notify you.
Reactivate all plugins.
Any problems, restore easyspace backups from control panel.
Ever started a job and thought “this is running on a bit longer than I expected”, then wondered whats going to happen when you go home and come back in to work tomorrow morning to find your remote session gone, which leaves you wondering “did that job complete?”.
Mmm, me too, which is where the nohup or disown commands come in. nohup (no hangup) is a well known job control utility which will prevent a process from reacting to the hangup signal when a shell is disconnected. Usually you’d preceed your actual command with it, e.g.
nohup rsync -auvc /Source/* /Destination/
but if your command is already running, you’re left wishing you’d nohup‘d it to start with – unless you’re running Solaris or AIX in which case the nohup command has a convenient -p switch to specify the process id (use ps -ef | grep rsync to obtain the PID of that long running data migration process, then nohup -p 9675 (or whatever the PID is of your running job).
If you’re not running Solaris or AIX, then pray you started the command in the bash shell (Linux default shell so more likely than not). If you did, then you can
to pause the current job running in the foreground, then use the
command to determine its job number (most likely 1 if there’s no other sysadmins running backgrounded jobs), then background the process with
to disconnect the process from the current shell. Running
again will show that your job is no longer in the list, but
will reveal that it is in fact still running.
Your shell can now be closed without the fear of your running job being killed with it. Yay.