on ( debian 11 / Xfce ) to show lightdm.conf at first I used this command
~$ /usr/sbin/lightdm --show-config
[Seat:*]
-----------
Sources:
B /usr/share/lightdm/lightdm.conf.d/01_debian.conf
B /usr/share/lightdm/lightdm.conf.d/01_debian.conf ---> same as above
C /etc/lightdm/lightdm.conf.d/lightdm.conf
D /etc/lightdm/lightdm.conf
then I tried
~$ sudo lightdm --show-config
[Seat:*]
----------
Sources:
A /usr/share/lightdm/lightdm.conf.d/01_debian.conf
B /etc/lightdm/lightdm.conf.d/lightdm.conf
C /etc/lightdm/lightdm.conf
which gives normal output. But even more puzzling, for me, is that if I use sudo with the first command, which I normally should not do, I get the right output :
~$ sudo /usr/sbin/lightdm --show-config
[Seat:*]
---------
Sources:
A /usr/share/lightdm/lightdm.conf.d/01_debian.conf
B /etc/lightdm/lightdm.conf.d/lightdm.conf
C /etc/lightdm/lightdm.conf
I tried nothing because I am completely puzzled by this problem. I have no idea whatsoever where to start looking or what to look for.
Related
Okay, hopefully I can explain this correctly as I have no idea what's causing this or how to resolve this.
For some reason bash commands (on a CentOS 6.x server) are displaying more information than "normally" and that causes issues with certain scripts. I have no clue if there is a name for this, but hopefully someone knows a solution for this.
First example.
Correct / good server:
[root#goodserver ~]# vzctl enter 3567
entered into CT 3567
[root#example /]#
(this is the correct behaviour)
Incorrect / bad server:
[root#badserver /]# vzctl enter 3127
Entering CT
entered into CT 3127
Open /dev/pts/0
[root#example /]#
With the "bad" server it will display more information as usual, like:
Entering CT
Open /dev/pts/0
It's like it parsing extra information on what it's doing.
Ofcourse the above is purely something cosmetic, however with several bash scripts we use, these issues are really issues.
A part of the script we use, uses the following command (there are more, but this is mainly a example of what's wrong):
DOMAIN=`vzctl exec $VEID 'hostname -d'`
The result of the above information is parsed in /etc/named.conf.
On the GOOD server it would be added in the named.conf like this:
zone "example.com" {
type master;
file "example.com";
allow-transfer {
200.190.100.10;
200.190.101.10;
common-allow-transfer;
};
};
The above is correct.
On the BAD server it would be added in the named.conf like this:
zone "Executing command: hostname -d
example.com" {
type master;
file "Executing command: hostname -d
example.com";
allow-transfer {
200.190.100.10;
200.190.101.10;
common-allow-transfer;
};
};
So it's add stuff of the action it does, in this example "Executing command: hostname -d"
Another example here when I run the command on a good server and on the bad server.
Bad server:
[root#bad-server /]# DOMAIN=`vzctl exec 3333 'hostname -d'`
[root#bad-server /]# echo $DOMAIN
Executing command: hostname -d example.com
Good server:
[root#good-server ~]# DOMAIN=`vzctl exec 4444 'hostname -d'`
[root#good-server ~]# echo $DOMAIN
example.com
My knowledge is limited, but I have tried several things checking rsyslog and the grub.conf, but nothing seems out of the ordinary.
I have no clue why it's displaying the extra information.
Probably it's something simple / stupid, but I have been trying to solve this for hours now and I really have no clue...
So any help is really appreciated.
Added information:
Both servers use: kernel.printk = 7 4 1 7
(I don't know if that's useful)
Well (thanks to Aaron for pointing me in the right direction) I finally found the little culprit which was causing all the issues I experienced with this script (which worked for every other server, so no need to change that obviously).
The issues were caused by the VERBOSE leven set in vz.conf (located in /etc/vz/ directory). There is an option in there called "VERBOSE" and in my case it was set to 3.
According to OpenVZ's website it does the following:
Increments logging level up from the default. Can be used multiple times.
Default value is set to the value of VERBOSE parameter in the global
configuration file vz.conf(5), or to 0 if not set by VERBOSE parameter.
After I changed VERBOSE=3 to VERBOSE=0 my script worked fine once again (as it did for every other server). :-)
So a big shoutout to Aaron for pointing me in the right direction. The answer is easy when you know where to look!
Sorry to say, but I am kinda disappointed by ndim's reaction. This is the 2nd time he was very unhelpful and rude in his response after that. He clearly didn't read the issue I posted correctly. Oh well.
I would make sure to properly parse the output of the command. In this case, we are only interested in lines of the form
entered into CT 12345
One way of doing this would be to pipe everything through sed and having sed print only the number when the line looks as above (untested, and I always forget which braces/brackets/parens need a backslash in front of them):
whateverthecommand | sed -n 's/^entered into CT ([0-9]{1,})$/\1/p'
I am new to BeagleBone Green Wireless (BBGW). I just read Derek Molloy's Exploring BeagleBone. Very good read, however, BBGW has Linux 4.4.9-ti-r25 and everything is quite different. Linux 4.4.9 no longer has the device tree source. Just has the device tree overlays (.dto). I am trying to experiment with the PWM's. I loaded am33xx_pwm-00A0.dtbo and BB-PWM1-00A0.dtbo overlays found in /lib/firmware. I presume these are default overlays for PWM1 but not sure.
export SLOTS=/sys/devices/platform/bone_capemgr/slots
export PINS=/sys/kernel/debug/pinctrl/44e10800.pinmux/pins
sudo sh -c "echo am33xx_pwm > $SLOTS"
sudo sh -c "echo BB-PWM1 > $SLOTS"
They appear to be loaded correctly,
root#beaglebone:/lib/firmware# cat $SLOTS
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
5: P-O-L- 0 Override Board Name,00A0,Override Manuf,am33xx_pwm
7: P-O-L- 1 Override Board Name,00A0,Override Manuf,BB-PWM1
However, I cannot find where to access PWM1's properties. Malloy says that they are in, /sys/devices/ocp.3/pwm_test_p9_22.15. I could not find that directory and the closest I could find was /sys/devices/platform/ocp/. There are several devices but nothing about PWM1. Where can I find the location of PWM1's properties? I want to change them using the echo command using this example,
sudo su
echo 5000 > duty
echo 10000 > period
echo 1 > run
If someone knows of a good document that would be helpful as well.
I know you said you are close to solving it but I got it to work..
Kernel: 4.4.30-ti-r64
Distro: Debian 8.6 Jessie
Now to load the PWM overlay...
My distro is from RCN and comes with the overlays pre-populated in my /lib/firmware/ folder. If you have the overlays there continue to step 4, if not step 2.
apt-get update
sudo apt install bb-cape-overlays
Load the overlay into the cape manager:
echo BB-PWM1 > /sys/devices/platform/bone_capemgr/slots
Ensure the overlay is loaded correctly by doing two things:
First make sure it is in the capemanager:
cat /sys/devices/platform/bone_capemgr/slots
output:
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-PWM1
The second is to make sure the pin is correctly muxed to do this:
cd /sys/kernel/debug/pinctrl/44e10800.pinmux
more pins | grep 848
the output should be similar to this :
pin 18 (44e10848.0) 00000006 pinctrl-single
You can look into the overlay to get a deeper understanding of what is going on but it is a little outside the scope of this question.
if you don't see the 00000006 output. Dont proceed. Reboot the BB and try again. This happened to me and a reboot solved the problem
So, the BB is now ready for PWM.
cd /sys/class/pwm
cd pwmchip0
echo 0 > export
cd pwm0
echo 1000000000 > period
echo 800000000 > duty_cycle
echo 1 > enable
Ta-da. it should work. Sorry for the lengthy response. I wanted to be thorough.
I followed the tutorial: http://www.teachmemicro.com/beaglebone-black-pwm-ubuntu-device-tree/
Edit:
This is for setting the PWM for P9_14
When I try to build for Raspberry Pi2, the option is raspi-2, right?
$ gyp_cobalt raspi-2
$ ninja -C out/raspi-2_debug cobalt
There currently is no raspi-2 configuration, but the raspi-1 configuration will run on a Raspberry Pi Zero, 1, 2, and 3. It won't take advantage of the Neon instruction set available on a Raspberry Pi 2, but it will run. Both the Broadcom 2835 (RasPi 0,1) and 2836 (RasPi 2) are 32-bit ARM chips, so binaries compiled to a common subset of the instruction set should run on both devices.
Creating a raspi-2 configuration wouldn't be too difficult.
$ cd src/starboard/raspi
$ cp -R 1/ 2
And modify src/starboard/rapi/2/gyp_configuration.gypi and src/starboard/rapi/2/gyp_configuration.py to refer to 'raspi-2' where they refer to 'raspi-1'.
Then one could furthet modify gyp_configuration.gypi to pass in more appropriate compiler flags for a Raspberry Pi 2. One might also want to set these properties, to enable Neon assembly optimizations in libwebp:
'arm_version': 7,
'armv7': 1,
'arm_neon': 1,
Thanks.
I put it all together.
$ cd ~/
$ git clone https://cobalt.googlesource.com/cobalt
$ cd cobalt/src/startboard/raspi
$ cp -R 1/ 2
$ cd 2/
$ vi gyp_configuration.gypi
Edit line 37-40 and change rasp-1 to rasp-2 at line 167-180.
# RasPi 2 is ARMv7
'arm_version': 7,
'armv7': 1,
'arm_neon': 1,
....
'default_configuration': 'raspi-2_debug',
'configurations': {
'raspi-2_debug': {
'inherit_from': ['debug_base'],
},
'raspi-2_devel': {
'inherit_from': ['devel_base'],
},
'raspi-2_qa': {
'inherit_from': ['qa_base'],
},
'raspi-2_gold': {
'inherit_from': ['gold_base'],
},
Then,
$ vi gyp_configuration.py
Edit line 14 and change rasp-1 to rasp-2 at line 25.
"""Starboard Raspberry Pi 2 platform configuration for gyp_cobalt."""
....
return _PlatformConfig('raspi-2')
Then, set $RASPI_HOME like the description of a manual.
$ export RASPI_HOME=~/raspi-tools
$ cd ~/cobalt/src/
$ cobalt/build/gyp_cobalt raspi-2
$ ls out/
./
../
raspi-2_debug/
raspi-2_devel/
raspi-2_gold/
raspi-2_qa/
$ ninja -C out/raspi-2_debug cobalt
But clang++ command is not found.
And there is not llvm-build in the following path
cobalt/src/third_party/
Where is it ?
update: the error only occurs when logged into R from within emacs
what works:
When I ssh into a remote server and run
$ ./foo.rb
from the bash shell, it works. Furthermore, if I launch R and execute
$ R
system('./foo.rb')
I am in a group with permission to read/write/execute the file. File permissions are -rwxrwx---
what doesn't work:
Launch emacs and start an R session:
M-x R
ssh-myserver:.
system('./foo.rb')
I get the following error:
ruby: Permission denied -- foo.rb (LoadError)
why is this? Is there a way to work around this?
I can not find any information from ?system or ?system2
Here is the output from sessionInfo()
> sessionInfo()
R version 2.12.2 (2011-02-25)
Platform: x86_64-redhat-linux-gnu (64-bit)
locale:
[1] C
attached base packages:
[1] grid stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] PECAn_0.1.1 xtable_1.5-6 gridExtra_0.7 RMySQL_0.7-5
[5] DBI_0.2-5 ggplot2_0.8.9 proto_0.3-8 reshape_0.8.3
[9] plyr_1.6 rjags_2.2.0-2 coda_0.13-5 lattice_0.19-17
[13] randtoolbox_1.09 rngWELL_0.9 MASS_7.3-11 XML_3.2-0
loaded via a namespace (and not attached):
[1] digest_0.4.2
Warning message:
'DESCRIPTION' file has 'Encoding' field and re-encoding is not possible
output of 'id' and 'env' from ssh and emacs, per comment by #sarnold (changed user names, group names, and ip addresses)
1. server
1.1 'id'
uid=1668(dleb) gid=1668(dleb) groups=117(ebusers),159(lab_admin),166(lab),1340(pal_web),1668(dleb)
1.2 'env'
LC_PAPER=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
SHELL=/usr/local/bin/system-specific
KDE_NO_IPV6=1
SSH_CLIENT=888.888.888.88 51857 22
NCARG_FONTCAPS=/usr/lib64/ncarg/fontcaps
LC_NUMERIC=en_US.UTF-8
USER=dleb
LS_COLORS=
LC_TELEPHONE=en_US.UTF-8
KDEDIR=/usr
NCARG_GRAPHCAPS=/usr/lib64/ncarg/graphcaps
MAIL=/var/mail/dleb
PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/opt/dell/srvadmin/bin
LC_IDENTIFICATION=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
R_LIBS=/home/a-m/dleb/lib/R
PWD=/home/dleb
NCARG_ROOT=/usr
KDE_IS_PRELINKED=1
LANG=en_US.UTF-8
NCARG_DATABASE=/usr/lib64/ncarg/database
MODULEPATH=/usr/share/Modules/modulefiles:/etc/modulefiles
LOADEDMODULES=
LC_MEASUREMENT=en_US.UTF-8
NCARG_LIB=/usr/lib64/ncarg
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
NCARG_NCARG=/usr/share/ncarg
SHLVL=1
HOME=/home/a-m/dleb
LOGNAME=dleb
CVS_RSH=ssh
SSH_CONNECTION=888.888.888.88 51857 999.999.999.99 22
LC_CTYPE=en_US.UTF-8
MODULESHOME=/usr/share/Modules
LESSOPEN=|/usr/bin/lesspipe.sh %s
DISPLAY=localhost:15.0
LC_TIME=en_US.UTF-8
G_BROKEN_FILENAMES=1
LC_NAME=en_US.UTF-8
_=/bin/env
emacs/ess R session
2.1 system('id')
uid=1668(dleb) gid=1668(dleb) groups=117(ebusers),159(lab_admin),166(lab),1340(pal_web),1668(dleb)
2.2 system('env')
LN_S=ln -s
R_TEXI2DVICMD=/usr/bin/texi2dvi
LC_PAPER=en_US.UTF-8
SED=/bin/sed
LC_ADDRESS=en_US.UTF-8
R_PDFVIEWER=/usr/bin/xdg-open
LC_MONETARY=en_US.UTF-8
HOSTNAME=ebi-forecast
R_INCLUDE_DIR=/usr/include/R
R_PRINTCMD=lpr
SHELL=/usr/local/bin/system-specific
TERM=dumb
AWK=gawk
HISTSIZE=1
R_RD4DVI=ae
SSH_CLIENT=888.888.888.88 51159 22
KDE_NO_IPV6=1
R_RD4PDF=times,hyper
R_PAPERSIZE=a4
NCARG_FONTCAPS=/usr/lib64/ncarg/fontcaps
PERL=/usr/bin/perl
LC_NUMERIC=en_US.UTF-8
SSH_TTY=/dev/pts/14
LC_ALL=C
EMACS=t
USER=dleb
LC_TELEPHONE=en_US.UTF-8
LS_COLORS=
LD_LIBRARY_PATH=/usr/lib64/R/lib:/usr/local/lib64:/usr/lib/jvm/jre/lib/amd64/server:/usr/lib/jvm/jre/lib/amd64:/usr/lib/jvm/java/lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib
TAR=/bin/gtar
ENV=
R_ZIPCMD=/usr/bin/zip
KDEDIR=/usr
PAGER=/usr/bin/less
NCARG_GRAPHCAPS=/usr/lib64/ncarg/graphcaps
R_GZIPCMD=/usr/bin/gzip
PATH=/bin:/usr/bin:/usr/sbin:/usr/local/bin
LC_COLLATE=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
EGREP=/bin/grep -E
PWD=/home/a-m/dleb/pecan
INPUTRC=/etc/inputrc
R_LIBS=/home/a-m/dleb/lib/R
NCARG_ROOT=/usr
R_SHARE_DIR=/usr/share/R
WHICH=/usr/bin/which
EDITOR=vi
LANG=en_US.UTF-8
KDE_IS_PRELINKED=1
R_LIBS_SITE=/usr/local/lib/R/site-library:/usr/local/lib/R/library:/usr/lib64/R/library:/usr/share/R/library
M ODULEPATH=/usr/share/Modules/modulefiles:/etc/modulefiles
NCARG_DATABASE=/usr/lib64/ncarg/database
LC_MEASUREMENT=en_US.UTF-8
LOADEDMODULES=
PS3=
R_BROWSER=/usr/bin/xdg-open
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
NCARG_LIB=/usr/lib64/ncarg
HOME=/home/a-m/dleb
SHLVL=1
NCARG_NCARG=/usr/share/ncarg
R_ARCH=
TR=/usr/bin/tr
MAKE=make
R_UNZIPCMD=/usr/bin/unzip
LOGNAME=dleb
CVS_RSH=ssh
LC_CTYPE=en_US.UTF-8
SSH_CONNECTION=888.888.888.88 51159 999.999.999.99 22
R_BZIPCMD=/usr/bin/bzip2
MODULESHOME=/usr/share/Modules
LESSOPEN=|/usr/bin/lesspipe.sh %s
PROMPT_COMMAND=
R_HOME=/usr/lib64/R
DISPLAY=localhost:22.0
R_PLATFORM=x86_64-redhat-linux-gnu
INSIDE_EMACS=23.2.1,tramp:2.1.18-23.2
R_LIBS_USER=~/R/x86_64-redhat-linux-gnu-library/2.12
LC_TIME=en_US.UTF-8
R_DOC_DIR=/usr/share/doc/R-2.12.2
R_SESSION_TMPDIR=/tmp/RtmpqA6bpJ
HISTFILE=/home/a-m/dleb/.tramp_history
G_BROKEN_FILENAMES=1
LC_NAME=en_US.UTF-8
_=/bin/env
Assuming you started up R as the same user, you do. You error is not coming from a permissions problem for foo.rb, however, or else your shell would be giving the error. (i.e. sh: ./test.rb: Permission denied; see example below). Here, ruby itself is giving the error. Without knowing exactly what is in your foo.rb, I would suggest digging in there to see what it is trying to load/source, and checking the permissions on those.
#!/usr/bin/env ruby
puts 'Hello world'
Now in R....
> system('ls -l test.rb')
-rw-r--r-- 1 jcolby staff 40 Oct 21 08:23 test.rb
> system('./test.rb')
sh: ./test.rb: Permission denied
> system('chmod a+x test.rb')
> system('./test.rb')
Hello world
I presume the M ODULEPATH in the Emacs-derived output is simply a copy and paste typo.
The differences between the two env outputs is much greater than I expected; I've selected the ones that look slightly suspicious to me:
$ diff -u works fails
--- works 2011-10-24 15:04:02.000000000 -0700
+++ fails 2011-10-24 15:12:36.000000000 -0700
...
+LD_LIBRARY_PATH=/usr/lib64/R/lib:/usr/local/lib64:/usr/lib/jvm/jre/lib/amd64/server:/usr/lib/jvm/jre/lib/amd64:/usr/lib/jvm/java/lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib
...
-PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/opt/dell/srvadmin/bin
-PWD=/home/dleb
...
+PATH=/bin:/usr/bin:/usr/sbin:/usr/local/bin
...
+PWD=/home/a-m/dleb/pecan
...
In the emacs-derived session, your LD_LIBRARY_PATH environment variable may be changing specifics of which dynamically linked libraries are being used when executing ruby. If you ssh in to your server and execute your foo.rb with the changed LD_LIBRARY_PATH, does it work or fail?
LD_LIBRARY_PATH=/usr/lib64/R/lib:/usr/local/lib64:/usr/lib/jvm/jre/lib/amd64/server:/usr/lib/jvm/jre/lib/amd64:/usr/lib/jvm/java/lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib ./foo.rb
The PATH environment variable between the two sessions is different; perhaps you have permission to execute /usr/local/bin/ruby (or the libraries in /usr/local/lib/ruby/) but not /usr/bin/ruby (or the libraries in /usr/lib/ruby/). Does your script use #!env ruby or does it use #!/usr/bin/ruby (or some other fixed path)?
Your pwd in one instance is /home/dleb, the other /home/a-m/dleb/pecan -- but HOME is set to /home/a-m/dleb on both systems. Is /home/dleb a symbolic link or does it actually exist separate from /home/a-m/dleb? (This really is grasping at straws -- I don't think this is it, but this problem is baffling.)
One last thing to consider: is your server confined with a tool such as AppArmor, SELinux, TOMOYO, or SMACK? Any of these mandatory access control tools can prevent an application from writing in specific locations, perhaps they aren't yet configured for your site. Check dmesg(1) output to see if there are any rejection messages, most or all these tools log to dmesg(1) if auditd(8) isn't running.
I'm using ab to do some load testing, and it's important that the supplied querystring (or POST) parameters change between requests.
I.e. I need to make requests to URLs like:
http://127.0.0.1:9080/meth?param=0
http://127.0.0.1:9080/meth?param=1
http://127.0.0.1:9080/meth?param=2
...
to properly exercise the application.
ab seems to only read the supplied POST data file once, at startup, so changing its content during the test run is not an option.
Any suggestions?
You're going to need to use a more full-featured benchmarking tool like jMeter for this.
Add my recommendation for jMeter...it works very well!
You could also create a script that creates a second script with something like:
ab -n 1 -c 1 'http://yoursever.com/method?param=0' &
ab -n 1 -c 1 'http://yoursever.com/method?param=1' &
ab -n 1 -c 1 'http://yoursever.com/method?param=2' &
ab -n 1 -c 1 'http://yoursever.com/method?param=3' &
ab -n 1 -c 1 'http://yoursever.com/method?param=4' &
But that's only really useful if you're trying to simulate load and observe your server. The actual benchmarks will have to be collated if you want to check ab performance. At that point I'd just use jMeter. For my use, I just need to simulate load and the ab processes are light enough that running 100 like this is no problem.
Here is patched version of ab or patch:
http://www.andboson.com/?p=1372
this version is included that patch http://chrismiles.info/dev/testing/ab
also can read many post-data line by line
upd:
sample request:
./ab -v1 -n2 -c1 -T'application/json' -ppostfile http://api.webhookinbox.com/i/HX6mC1WS/in/
postfile content:
{"data1":1, "data2":"4"}
{"data0":0, "x":"y"}
upd2:
also alternative
https://github.com/andboson/ab-go