I have a systemd foo.slice with cgroup setting CPUShares.
My idea is to change the setting at certain point during the system startup, which will be triggered by a systemd service.
I do some test work to check how to change the setting at runtime.
In the foo.slice I defined CPUShares=256. Which will cause cat /sys/fs/cgroup/cpu/foo.slice/cpu.shares 256.
And will get the following lines by gdbus introspect:
interface org.freedesktop.systemd1.Slice {
methods:
signals:
properties:
#org.freedesktop.DBus.Property.EmitsChangedSignal("false")
readonly s Slice = '-.slice';
#org.freedesktop.DBus.Property.EmitsChangedSignal("false")
readonly s ControlGroup = '/foo.slice';
#org.freedesktop.DBus.Property.EmitsChangedSignal("false")
readonly b CPUAccounting = false;
#org.freedesktop.DBus.Property.EmitsChangedSignal("false")
readonly t CPUShares = 256;
I try to change the CPUShares by invoking the method:
#org.freedesktop.systemd1.Privileged("true")
SetProperties(in b arg_0,
in a(sv) arg_1);
using:
gdbus call --system --dest org.freedesktop.systemd1 --object-path /org/freedesktop/systemd/unit/foo_2eslice --method org.freedesktop.systemd1.Unit.SetProperties true "[('CPUShares', <#t 2048>)]"
And I will get
#org.freedesktop.DBus.Property.EmitsChangedSignal("false")
readonly t CPUShares = 2048;
But I still get cat /sys/fs/cgroup/cpu/foo.slice/cpu.shares 256.
After I restart the slice:
gdbus call --system --dest org.freedesktop.systemd1 --object-path /org/freedesktop/systemd1/unit/foo_2eslice --method org.freedesktop.systemd1.Unit.Restart 'replace'
I will get
cat /sys/fs/cgroup/cpu/foo.slice/cpu.shares 2048
I use systemd 211.
I wish to know more detail about this behavior or if there are better solutions, i.e. wish to get some hint to change the CPUShares at runtime with systemd.
If you are trying to change the cpu shares before systemd reaches its default.target you need to use StartupCPUShares=.
Related
I am going through dbus-python tutorial.
https://dbus.freedesktop.org/doc/dbus-python/tutorial.html#interfaces-and-methods
The example provided does not work for me. I replaced the eth0 with 1 but still it throws an error.
import dbus
bus = dbus.SystemBus()
eth0 = bus.get_object('org.freedesktop.NetworkManager',
'/org/freedesktop/NetworkManager/Devices/eth0')
eth0_dev_iface = dbus.Interface(eth0,
dbus_interface='org.freedesktop.NetworkManager.Devices')
props = eth0_dev_iface.getProperties()
Error:
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send
message, 2 matched rules; type="method_call", sender=":1.4371" (uid=78105 pid=8231
comm="python3 " label="unconfined") interface="org.freedesktop.NetworkManager.Devices"
member="getProperties" error name="(unset)" requested_reply="0" destination=":1.11"
(uid=0 pid=1122 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
Also there is this below statement
For instance, each NetworkManager object representing a network interface implements the interface org.freedesktop.NetworkManager.Devices, which has methods like getProperties.
I checked with d-feet, somehow the interface of network manager does not have getProperties method
'/org/freedesktop/NetworkManager/Devices/eth0' is not a D-Bus path that you'll see on NetworkManager's D-Bus API.
You said, you were checking with d-feet. There you'll see that on NetworkManager's D-Bus API, objects commonly have a number at the end. So D-Bus paths to device "objects" are named like /org/freedesktop/NetworkManager/Devices/1.
Try also busctl tree org.freedesktop.NetworkManager.
I checked with d-feet, somehow the interface of network manager does not have getProperties method
NetworkManager's D-Bus API doesn't literally have a getProperties method. It implements the standard D-Bus API with org.freedesktop.DBus.Properties interface as specified (https://dbus.freedesktop.org/doc/dbus-specification.html). Maybe the python bindings expose that as a getProperties() method...
Try:
$ busctl call org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/Devices/1 org.freedesktop.DBus.Properties Get ss org.freedesktop.NetworkManager.Device Path`
and
$ busctl -j call org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/Devices/1 org.freedesktop.DBus.Properties GetAll s org.freedesktop.NetworkManager.Device
I am developing shared library and subagent for net-snmp. I need to send v3 traps for specific hardware events. I would like to know what value need to be filled in the context value of send_v3trap API.
void send_v3trap(netsnmp_variable_list * vars,const char * context )
Is this context value, same as user defined engine id ? i.e., the one which needs to be configured in snmptrapd.conf as below ?
createUser -e ENGINEID myuser SHA "my authentication pass" AES "my encryption pass"
More on configuring in this link
There is an example source code available for sending
v2traps
By looking at the net-snmp source code, send_v3trap calls internally send_v2trap and eventually,
/* A context name was provided, so copy it and its length to the v2 pdu
* template. */
if (context != NULL)
{
template_v2pdu->contextName = strdup(context);
template_v2pdu->contextNameLen = strlen(context);
}
Answering my own question.
"context" value can be filled with
value returned by "snmpv3_get_engineID"
NULL
As long as, configurations are proper in terms of v3 i.e., trapsess -v3 specified in the host and on the target, engineid of net-snmp is specified, then everything works fine.
Only unclear part still is, if someone is able to send v3 traps without specifying "context", in which scenario would it be useful really !
Is it possible to determine if SoapUI (ReadyAPI) is started
via testrunner.bat
by the user (running in interactive UI-mode)
I know that you can retrieve the current environment using this groovy script code:
def env = testRunner.testCase.testSuite.project.activeEnvironment.name
However I wonder what value this will return when running via the command-line (testrunner.bat) ; will it return the active environment from the test project, or will it be null/empty ?
Update (use-case)
The user case is that depending on the way the tests are run. In case of testrunner.bat I want to be able to set the environment to a fixed value. Else I want enable the user to select the environment manually.
Note that the some environment settings like EndPoints for each environment are defined a pre-defined XML file.
Update (possible solution)
#albciff
On the latest version from ReadyAPI (1.9.0), this does not work as you described.
testrunner.bat returns SoapUIProTestCaseRunner
running via ui returns InProcessSoapUIProTestCaseRunner
When using this code:
def runner = com.eviware.soapui.SoapUI.getCmdLineRunner();
log.info "runner = [" + runner.getClass().getSimpleName() + "]"
A more easier way to detect this would be:
if (com.eviware.soapui.SoapUI.isCommandLine()) {
// todo
}
Found at community.smartbear.com
I think that there is no property inside SOAPUI to difference between how it's executed. In fact I test your proposal:
def env = testRunner.testCase.testSuite.project.activeEnvironment.name
And it returns Default for both cases (from UI and using testrunner).
A possible workaround to do so, it's for example to pass a project property parameter in the CLI of the testrunner execution; and then in your code check for this parameter to detect how the project is launched.
To pass a project property you've to use -Pname=value. So for example launch the testrunner using:
testrunner -r -I <path/To/yourProject.xml> -PrunningBy=testRunner
And then in your code you can get the property and check for this content to decide if it's running by testrunner or from the UI, something like:
def runningBy = testRunner.testCase.testSuite.project.getPropertyValue('runningBy')
if(runningBy){
// it's not null so is launched from testRunner
}else{
// it's null, so is launched from UI
}
UPDATE
After reviewing the API seems that it's possible thought the follow method:
com.eviware.soapui.SoapUI.getCmdLineRunner()
It returns null when executed from UI, instead when executed from testrunner it returns and instance of com.eviware.soapui.tools.CmdLineRunner.
So you can use something like:
def clr = com.eviware.soapui.SoapUI.getCmdLineRunner()
if(clr){
// it's not null so is launched from testRunner
}else{
// it's null, so is launched from UI
}
The setup:
An older project I've inherited has a lot of legacy instrumentation tests and I would like to impose a timeout on them, since a lot of them can hang indefinitely and this makes it hard to get a test report. I'm in the process of updating the tests to be Junit4 style, but at the moment they're all extending ActivityInstrumentationTestCase2.
Tried so far:
In the documentation for AndroidJUnitRunner it says to set this flag:
Set timeout (in milliseconds) that will be applied to each test: -e timeout_msec 5000
...
...
All arguments can also be specified in the in the AndroidManifest via a meta-data tag
I've tried adding AndroidJUnitRunner configuration to the app manifest and the test manifest, but the timeout_msec meta-data item has had no effect so far.
You can use a rule to provide a timeout for each test in the class as shown below.
#Rule public Timeout timeout = new Timeout(120000, TimeUnit.MILLISECONDS);
You can also specify per test basis timeouts by using the following
#Test(timeout = 100) // Exception: test timed out after 100 milliseconds
public void test1() throws Exception {
Thread.sleep(200);
}
You can read more about the differences using this link
https://stackoverflow.com/a/32034936/2128442
I have a Windows Service that monitors a COM port connected to a vendors hardware. This is a very busy piece of hardware that is constantly polling other devices on the wire (this is a twisted-pair RS485 "network"). My software needs to emulate X number of hardware devices on this wire, so I've got a multi-threaded thing going on with a multi-tiered state machine to keep track of where the communications protocol is at any moment.
Problem is with a Windows Service (this is my first one, BTW) is that you need some debugging to let you know if stuff is working properly. When I was first developing this state machine/multi-thread code I had a windows form with a RichTextBox that displayed the ASCII chars going back-n-forth on the line. Seems like I can't really have that GUI niceness with a service. I tried opening a form in the service via another program that sent the service messages that are received via the OnCustomCommand() handler but it didn't seem to work. I had "Allow service to interact with desktop" checked and everything. I was using the Show() and Hide() methods of my debug form.
I guess I don't need to see all of the individual characters going on the line but man that sure would be nice (I think I really need to see them :-) ). So does anyone have any crazy ideas that could help me out? I don't want to bog down the system with some IPC that isn't meant for the voluminous amount of data that is sure to come through. It will only be very short-term debugging though, just confirmation that the program, the RS485-to-USB dongle, and hardware is all working.
Use OutputDebugString to write to the debugging buffer and then use DebugView to watch it. If you're running on Windows XP or earlier, then you can use PortMon to see the raw bytes going through the serial port. The advantage over a log file is that there's very little overhead, particularly when you're not watching it. You can even run DebugView from another machine and monitor your service remotely.
I dunno if it will work for you, but I always build my services with a extra Main that build them as console app to get debug output.
Edit:
Some example:
class Worker : ServiceBase
{
#if(RELEASE)
/// <summary>
/// The Main Thread where the Service is Run.
/// </summary>
static void Main()
{
ServiceBase.Run(new Worker());
}
#endif
#if(DEBUG)
public static void Main(String[] args)
{
Worker worker = new Worker();
worker.OnStart(null);
Console.ReadLine();
worker.OnStop();
}
#endif
// Other Service code
}
You could write the output to a log file and then use another application to watch that file. This question about "tail" outlines several options for watching log files with windows.
What I usually do when working on a Windows Service is to create it so that it can be run either as a service, or as a plain old command-line application. You can easily check whether you are running as a service by checking Environment.UserInteractive. If this property is true, then you are running from the command line. If the property is false, then you are running as a service. Add this code to Program.cs, and use it where you would normally call ServiceBase.Run(servicesToRun)
/// <summary>Runs the provided service classes.</summary>
/// <param name="servicesToRun">The service classes to run.</param>
/// <param name="args">The command-line arguments to pass to the service classes.</param>
private static void RunServices(IEnumerable<ServiceBase> servicesToRun, IEnumerable args)
{
var serviceBaseType = typeof(ServiceBase);
var onStartMethod = serviceBaseType.GetMethod("OnStart", BindingFlags.Instance | BindingFlags.NonPublic);
foreach (var service in servicesToRun)
{
onStartMethod.Invoke(service, new object[] { args });
Console.WriteLine(service.ServiceName + " started.");
}
Console.WriteLine("Press any key to exit.");
Console.ReadKey();
var onStopMethod = serviceBaseType.GetMethod("OnStop", BindingFlags.Instance | BindingFlags.NonPublic);
foreach (var service in servicesToRun)
{
onStopMethod.Invoke(service, null);
Console.WriteLine(service.ServiceName + " stopped.");
}
}
Now you can debug your service, set breakpoints, anything you want. When you run your application, you'll get a console window, appropriate for displaying console messages, and it will stay open until you hit a key.
I'm answering my own question here. I tried a couple of suggestions here but here's what I ended up doing...
I created a Windows Form application with a single Button and RichTextBox. This application constructed a NamedPipeServerStream on it's end. The Button's job was to send either "debug on" (command 128) or "debug off" (129) to the Windows Service. The initial value was "debug off". When the button was clicked, a command of 128 was sent to the Windows Service to turn debugging on. In the Windows Service this triggered an internal variable to be true, plus it connected to the Form application with a NamedPipeClientStream and started sending characters with a BinaryWriter as they were received or sent on the COM port. On the Form side, a BackgroundWorker was created to WaitForConnection() on the pipe. When it got a connection, a BinaryReader.ReadString() was used to read the data off of the pipe and shoot it to the RichTextBox.
I'm almost there. I'm breaking my pipe when I click the debug button again and a subsequent click doesn't correctly redo the pipe. All in all I'm happy with it. I can post any code if anyone is interested. Thanks for the responses!