Are there any plans to add the ability to create services? man page: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html

If you need sudo, you should execute the bin executable with sudo. The incode support was dropped due to security reason.

How can I do this? If I do this: $cmd = "php_systemctl"; \SystemCtl\SystemCtl::setBinary("sudo $cmd"); I get an error: sh: sudo /home/.../php_systemctl: No such file or directory

This PR adds three new methods to help get additional information about services. We are aiming to use this library to display information about several services on a web dashboard, with the potential management of these being a secondary concern.

To this end, I've added some additional info methods:

• isActiveRaw(): retrieve the raw string output of the is-active command. We need this as we use some 'oneshot' services, which can be 'inactive' (as opposed to failed) under normal circumstances. Simply checking them to see if they are 'active', as the normal isActive() method does, is not enough for us: we need to raw response from the systemctl command.
• isEnabledRaw(): retrieve the raw string output of the is-active command. We don't strictly need the output of this but I added it for completeness.
• show(): retrieve the raw string output of the show command but parsing it to an array. We need some more detailed information like the time a 'oneshot' last ran, and potentially the ExecStart line to see the command actually run for debugging. This method takes the (extensive) output of the show command and makes it available to be easily consumed via a correctly keyed array of the output of the command.

Happy to make changes to the above to better conform with your library. I just quickly added these methods so we could access this additional systemd information.

AssertSame reports an error if the two elements do not share type and value. For example: this code $this->assertEquals(3, true); give uns true :-//// Please use assertSame, not assertEquals

https://github.com/symfony/process/blob/master/CHANGELOG.md#400

The changelog does not look like something that would concern this library. Could you make the constraint allow either ^3.0 or ^4.0, please?

I have restructured the tests a little into integration and unit tests.

All of your test are still there and functional. Included are some new ones and a little change regarding the instance name obtain process. It did not take the suffixes into account, which one could possibly add to the name of the unit.

As you will see, I have add a UnitStub, which is used to test your AbstractUnit class now and in my other PR which regards new commands like 'isActive' and 'isEnabled'.

It would be great if this PR would be merged, because my other one relies on it. I have split those two up, because it appeared a little heavy to me to restructure tests and introduce a new future in one go. I hope you like it :)

If you have any questions, I'd be glad to answer them.

See: https://blog.codito.dev/2022/11/composer-binary-only-docker-images/

Additionally I added support for missing PHP versions through Docker Compose 🙂

Change log

• Using the assertSame to make assertion equals strict.
• Fixing the following coding style via PHP_CodeSniffer:

FILE: ...hp/systemctl-php/src/Exception/UnitTypeNotSupportedException.php
----------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------
 11 | ERROR | [x] Opening brace must not be followed by a blank
    |       |     line (PSR12.Classes.OpeningBraceSpace.Found)
----------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------

When running the vendor/bin/phpunit with php-7.4 and PHPUnit 9.4.x versions, it presents following message:

PHPUnit 9.4.2 by Sebastian Bergmann and contributors.

Warning:       Your XML configuration validates against a deprecated schema.
Suggestion:    Migrate your XML configuration using "--migrate-configuration"!

And I think we can consider using the vendor/bin/phpunit --migrate-configuration to resolve this issue.

Fix OutputFetcher to properly fetch only the unit name.

Introduce new abstract method 'getUnitSuffix'

Revert AbstractUnit tests back to use UnitStub.

Fix command execution.

Fix Integration test for unit.

Change fetching of specific units from simply instacing them to properly fetching them from the systemctl output.

Fix command execution to apply to correct unit.

Add PHPDoc.

First of all, the Device unit type should implement the UnitInterface similar to the Timer or Service. Despite that everything, that is possible with a Timer should also be possible with a Device.

In the most simple case, you only need to provide the Device class implenting the UnitInterface extending AbstractUnit. The class should provide the correct suffix.

For more information about a Unit or Device see systemd documentation: https://www.freedesktop.org/software/systemd/man/systemd.unit.html https://www.freedesktop.org/software/systemd/man/systemd.device.html

Also see PR #27 from @peter279k for reference.

Changed log

• Improving the Composer option strategy for adding the --ignore-platform-req=php when running tests with PHP 8.x.
• Improving the Composer option strategy for without using the --ignore-platform-req=php when running tests with PHP 7.x.

Currently the UnitInstaller does not work with user scope. The $installPath is fix for system scope installations.

This should work similar to switching the scope to find a unit.

$systemCtl->user()->install($template); // default: ~/.config/systemd/user/
$systemCtl->system()->install($template); // default: /etc/systemd/system/

user home should be retrieved automatically. http://php.net/manual/en/function.posix-getpwuid.php

To resolve the paths we should use the currently empty PathResolver

I'm no expert on systemctl or its related technology, far from it.
I do know that systemctl and systemctl --user are two separated concepts on the linux distro I'm working with.

At first glance it doesn't seem possible to add the option user to the command.

Running ->getService('test') works if the unit test is configured as a system unit.

$ systemctl status test

Running ->getService('test') works if the unit test is configured as a user unit but throws an (expected) UnitNotFoundException exception.

$ systemctl --user status test

I hope this is on the road map or, better yet, I'm just missing the obvious solution.