have a module called phys_custom which defines a route, phys_custom.homepage (/homepage), which works fine, until I clear the cache, at which point it is no longer available.
Take a look at the following output. For now I need to always uninstall and reinstall my module every time I clear my cache. How would I go about debugging this?
$ drush #stewardd8.test -l phys cr
[success] Cache rebuild complete.
$ drush #stewardd8.test -l phys pmu phys_custom
[success] Successfully uninstalled: phys_custom
$ drush #stewardd8.test -l phys pm:enable phys_custom
[success] Successfully enabled: phys_custom
$ drush #stewardd8.test -l phys ev 'print_r(drupal_get_path("module", "phys_custom") . PHP_EOL)'
sites/phys/modules/phys_custom
$ drush #stewardd8.test -l phys ev 'print_r(\Drupal\Core\Url::fromRoute("phys_custom.homepage")->toString() . PHP_EOL)'
/homepage
$ drush #stewardd8.test -l phys cr
[success] Cache rebuild complete.
$ drush #stewardd8.test -l phys ev 'print_r(drupal_get_path("module", "phys_custom") . PHP_EOL)'
sites/phys/modules/phys_custom
$ drush #stewardd8.test -l phys ev 'print_r(\Drupal\Core\Url::fromRoute("phys_custom.homepage")->toString() . PHP_EOL)'
In RouteProvider.php line 201:
Route "phys_custom.homepage" does not exist.
I am using drush 9.6.2 and Drupal 8.6.15
I also opened an issue on Drupal.org
This is actually a core bug currently being worked on, Extensions in Multisite Directories Not Registered When Rebuilding Cache . The patch there fixes the issue.
This -l phys part in your command may be the cause of the issue.
Drush -l option purpose is to target a particular site in a multisite installations, it expects a URI :
-l <uri> , --uri=<uri> URI of the Drupal site to use.
The value of --uri should always be the same as when
the site is being accessed from a web browser (e.g. http://example.com)
That said, you shouldn't have to specify it as soon as the alias #stewardd8.test is well defined, by which I mean at least these 2 options appear in the corresponding site alias definition :
test:
root: /path/to/stewardd8
uri: http://example.com
With these options set correctly, you can run drush status and check the output :
$ drush #stewardd8.test status
Drupal version : 8.6.14
Site URI : http://example.com # <- as expected
But, if you override the site URI with -l phys things may not work as expected :
$ drush #stewardd8.test -l phys status
Drupal version : 8.6.14
Site URI : phys # <- invalid
So I suggest you start fixing this before digging further. Also you can add the -v, --verbose option to make drush more wordy, e.g. drush -v #stewardd8.test cr.
Then if it doesn't fix the missing route issue, I would scrutinize Drupal/PHP/SQL logs (in that order) especially when running the cache rebuild command.
Related
I am new to Rocket chip and trying to install rocket chip and execute simulation but while Creating rocket tool dir in Rocket chip setup as per README.md file, I am getting following error:
ar: illegal option combination for -r
usage: ar -d [-TLsv] archive file ...
ar -m [-TLsv] archive file ...
ar -m [-abiTLsv] position archive file ...
ar -p [-TLsv] archive [file ...]
ar -q [-cTLsv] archive file ...
ar -r [-cuTLsv] archive file ...
ar -r [-abciuTLsv] position archive file ...
ar -t [-TLsv] archive [file ...]
ar -x [-ouTLsv] archive [file ...]
make: *** [libfesvr.a] Error 1
This error comes while executing ./build.sh command.
I am using Mac OS sierra 10.12.06.
mac-vsanjay:rocket-tools vsanjay$ which ar
/usr/bin/ar
I open build.sh and found that this error is coming during execution of
build_project riscv-isa-sim --prefix=$RISCV command.
I also tried to modify Makefile which calls "ar" command:
## Heading ##
`$(AR) rcs -o $$# $$^`
but this cmd <build_project riscv-isa-sim --prefix=$RISCV> generates and overwrites makefile.
Please suggest how to overcome with AR error.
I'm using gitlab on a rasberry pi model 3 B. Following some information about my setup (sudo gitlab-rake gitlab:env:info):
System information
System: Raspbian 8.0
Current User: git
Using RVM: no
Ruby Version: 2.3.6p384
Gem Version: 2.6.13
Bundler Version:1.13.7
Rake Version: 12.3.0
Redis Version: 3.2.11
Git Version: 2.14.3
Sidekiq Version:5.0.5
Go Version: go1.3.3 linux/arm
GitLab information
Version: 10.6.0-rc3
Revision: 52fa89e
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: postgresql
URL: http://gitlab.example.com
HTTP Clone URL: http://gitlab.example.com/some-group/some-project.git
SSH Clone URL: git#gitlab.example.com:some-group/some-project.git
Using LDAP: no
Using Omniauth: no
GitLab Shell
Version: 6.0.3
Repository storage paths:
- default: /mnt/SeagateExpansion/GitLab/repositories
Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks
Git: /opt/gitlab/embedded/bin/git
After the gitlab update to version 10.6.0 I need to change the url again but when I do the necessary changes in /etc/gitlab/gitlab.rb and run sudo nano gitlab-ctl reconfigure I get the following error messages:
========================================================================
Error executing action `run` on resource 'ruby_block[directory resource:
/mnt/SeagateExpansion/GitLab]'
========================================================================
and
============================================================================
Error executing action `create` on resource
'storage_directory[/mnt/SeagateExpansion/GitLab]'
============================================================================
The result message says:
There was an error running gitlab-ctl reconfigure:
storage_directory[/mnt/SeagateExpansion/GitLab] (gitlab::gitlab-rails line 42) had an error: Mixlib::ShellOut::ShellCommandFailed: ruby_block[directory resource: /mnt/SeagateExpansion/GitLab] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/storage_directory.rb line 33) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of chmod 00700 /mnt/SeagateExpansion/GitLab ----
STDOUT:
STDERR: chmod: changing permissions of ‘/mnt/SeagateExpansion/GitLab’: Operation not permitted
---- End output of chmod 00700 /mnt/SeagateExpansion/GitLab ----
Ran chmod 00700 /mnt/SeagateExpansion/GitLab returned 1
So the problem seems to be, that the execution of the run and create command on the resource storage (GitLab folder on the external HDD [HDD = SeagateExpansion]) expects the permissions to be 700, right?
According to this errors I tried to change the permission of
the external HDD folder /mnt/SeagateExpansion/GitLab see the ls -l output:
drwxrwxrwx 1 root GitLabUser 0 Jan 4 17:55 GitLab
With the help of this post I tried to change the permission with the command:
sudo find /mnt/SeagateExpansion/GitLab -type d -exec chmod 700 {} \;
to the required permission 700. But the changes don't take affect. I also tried chmod -R 700 /mnt/SeagateExpansion/GitLab and executed the commands as root but the changes don't take effect. Even after restarting the raspberry pi. What am I doing wrong?
I also tried to change the options settings/flag of the HDD in /etc/fstab to user but this doesn't help ether.
I'm thankful for every hint and answer :).
Best regards,
Bredjo
I finally figured it out. The solution is to change the mount settings in the /etc/fstab. Because if you have the wrong options settings (see: https://en.wikipedia.org/wiki/Fstab) you are not able to change the permissions because its a ntfs filesystem.
So my old fstab entry was this:
UUID=FE820568820526AD /mnt/SeagateExpansion ntfs defaults,gid=GitLabUser 0 0
And the new entry is this:
UUID=FE820568820526AD /mnt/SeagateExpansion ntfs-3g permissions 0 0
Note that you need to install ntfs-3g to use it in fstab. And the permissions options only comes with ntfs-3g. See: https://www.tuxera.com/community/ntfs-3g-advanced/ownership-and-permissions/
After this change I executed again:
sudo gitlab-ctl reconfigure
Now the error disappeared and the permission 700 of the folder /mnt/SeagateExpansion/GitLab could be set. I also noticed that the owner of the GitLab folder was also changed to user git after the reconfiguration:
drwx------ 1 git root 0 Jan 4 17:55 GitLab
That's because I don't need the option gid=GitLabUserany more.
Now everything works again :).
Follow this document http://docs.sulu.io/en/latest/book/getting-started.html at the end of installation process I got this error:
Target: cache
cache:clear ({"--no-optional-warmers":true,"--no-debug":true,"--no-interaction":true})
// Clearing the admin cache for the dev environment with debug true
[Symfony\Component\Filesystem\Exception\IOException]
Failed to remove directory "/home/vagrant/Code/sulu/var/cache/admin/de~/doctrine": .
sulu:build [-D|--nodeps] [--destroy] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-s|--shell] [--process-isolation] [-e|--env ENV] [--no-debug] [--] <command> [<target>]
Before that I was trying to set up file permissions with this:
HTTPDUSER=`ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1`
sudo setfacl -R -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX var/cache var/logs var/uploads var/uploads/* web/uploads web/uploads/* var/indexes var/sessions
sudo setfacl -dR -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX var/cache var/logs var/uploads var/uploads/* web/uploads web/uploads/* var/indexes var/sessions
and also had these errors:
setfacl: web/uploads: Operation not supported
setfacl: web/uploads/media: Operation not supported
setfacl: web/uploads/media: Operation not supported
My host OS : Ubuntu 16.04
Vagrant : v.1.9.3
VirtualBox : v.5
Homestead: v.5.2.1
Does anyone have successful installation Sulu CMS with Homestead?
What is the option to solve these my issues?
Sulu CMS looks very promising but unfortunately I could not install it locally still with many attempts.
UPDATE
After comment of Daniel I've tried other way to install Sulu but again got error at the very end of installation:
Executing builders
==================
Target: cache
cache:clear ({"--no-optional-warmers":true,"--no-debug":true,"--no-interaction":true})
// Clearing the admin cache for the dev environment with debug true
[Symfony\Component\Filesystem\Exception\IOException]
Failed to remove directory "/home/vagrant/Code/sulu/app/cache/admin/de~/annotations": .
Opened test.app in browser I see this error:
Fatal error: Uncaught
Symfony\Component\Debug\Exception\FatalThrowableError: Call to a member function getLocale() on null in /home/vagrant/Code/sulu/vendor/sulu/sulu/src/Sulu/Bundle/WebsiteBundle/Twig/Content/ContentPathTwigExtension.php on line 70
Symfony\Component\Debug\Exception\FatalThrowableError: Call to a member function getLocale() on null in /home/vagrant/Code/sulu/vendor/sulu/sulu/src/Sulu/Bundle/WebsiteBundle/Twig/Content/ContentPathTwigExtension.php on line 70
Tried to delete cache folders manually - the same error.
All console commands work fine.
Any ideas?
P.S. I have a good experience of installation other Symfony-based applications under Homestead and all went smooth basically (Sylius, eZ etc.). So I am very surprised....
To get around this, you need to remove this folder from the host machine, because it's an artifact from the previous process of trying to set things up and it's in god-mode, created by a no-longer existing almighty entity.
vagrant destroy (needed to release filesystem locks)
Remove folder on host: rm -rf .../sulu/app/cache/admin
type: nfs on folder binding
vagrant up
Should work then, encountered this same problem recently.
If you're using Homestead Improved, use the built-in "sulu" project type for a decent Nginx auto-setup:
sites:
- map: homestead.app
to: /home/vagrant/Code/Project/web
type: sulu
On Azure CentOS VM while starting a custom application server that rely on FLEXnet license, I got the following error:
Error checking out license: System clock has been set back.
Feature: ep_u
License path: /opt/MyApplication/license/MyApplication-license.dat:
FLEXnet Licensing error:-88,309
For further information, refer to the FLEXnet Licensing documentation,
available at "www.flexerasoftware.com".
After searching on the net, I found that this error is due to some system file modified in the future.
As I didn't found a clear response to this issue, I write my own.
First on centOS I could check the current timezone:
ls -l /etc/localtime
And eventually update it
timedatectl list-timezones | grep Paris
sudo timedatectl set-timezone Europe/Paris
Then I need to check if my system have directories or files with a date in the future:
cd /
sudo find . -newermt "1 days"|more
I dont know why I have some results here but this command return me a lots of files and directory, event virtual file like /dev /sys /proc...
I finally fix this issue by updating timestamp of some working files/directory. In the previous results I fixed /etc and /var directories.
Here is the command to fix (reset future date) a given directory content (ex. /var) and set the current date for each entry (having a date in the future) :
cd /var
sudo find . -newermt "1 days"|sudo xargs touch
hope this helps
I guess this can help:
$ cd /
$ touch ref_file
$ find . -newer ref_file
$ find . -newer ref_file -exec touch {} \;
If I am logged in as root and cd to a domain user folder such as /home/mysite/www and I then use drush as follows
drush site-install standard --account-name=mysite --account-pass= "*****"
--db-url=mysql://my_site_admin:"*****"#localhost/my_site
It installs everything as root:root for uid:gid and the site produces error
SoftException in Application.cpp:357: UID of script "/home/sites/mx3/public_html
/index.php" is smaller than min_uid,
How can I install using mysite:mysite for permissions while logged in as root?
You do not want to run a script as root, if it is not necessary. Never.
Instead you should run it as the user of this site.
Version 1:
$ sudo -i -u websiteuser
$ drush site-install ...
Version 2:
$ sudo -u websiteuser drush site-install ...
For version 1 the websiteuser needs to habe a valid login shell, because you login as this user and work in his shell session. You stay in websiteuser's login shell, until you explicitly logout.
For version 2 the drush command is run instead of the login shell. After the drush command, you are back in root shell.