On Wed, Mar 01, 2017 at 11:12:03PM +0100, Lennart Poettering wrote:
> Heya!
>
> Finally, here's systemd 233. Tons of new features, even more
> bugfixes. Enjoy!
>
> https://github.com/systemd/systemd/releases/tag/v233
>
> CHANGES WITH 233:
>
> * systemd will now optionally run "environme
On 03/01/2017 05:28 PM, Ian Pilcher wrote:
Per Lennart's response, systemd *should* be honoring the file context
rules when creating the directory. It's almost as if the directory is
being created with the proper context, but something is changing it
after the fact. I have absolutely no idea wh
On 03/01/2017 04:28 PM, cgzones wrote:
Can you try a transition from initrc_t or the interface
I've added a rule for initrc_t (although I'm 99% sure that is no longer
used under systemd):
type_transition init_t var_run_t : dir squoxy_var_run_t "squoxy";
type_transition initrc_t var_run_t :
Heya!
Finally, here's systemd 233. Tons of new features, even more
bugfixes. Enjoy!
https://github.com/systemd/systemd/releases/tag/v233
CHANGES WITH 233:
* The "hybrid" control group mode has been modified to improve
compatibility with "legacy" cgroups-v1 setups. Specifically
On Wed, 01.03.17 15:40, Ian Pilcher (arequip...@gmail.com) wrote:
> I am using systemd's RuntimeDirectory to create a directory for a
> service.
>
>RuntimeDirectory=squoxy
>
> This causes systemd to create /run/squoxy before starting my service,
> but I haven't been able to get the SELinux c
I am using systemd's RuntimeDirectory to create a directory for a
service.
RuntimeDirectory=squoxy
This causes systemd to create /run/squoxy before starting my service,
but I haven't been able to get the SELinux context set correctly on the
directory.
I've set file context rules for both /ru
Hello,
I submitted similar question but it got stuck with moderators due to screen
shot size.
The actual bug report (on ubuntu side) is here:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1661611
My main question is actually how to configure systemd to have global
timeout on
On 01.03.2017 20:23, Viktor Mihajlovski wrote:
> On 01.03.2017 19:44, Daniel P. Berrange wrote:
> [...]
> replying on the list, a bit lengthy
>>
>> Ok, my guest has 4 disks
>>
>> - sda - virtio-scsi, over virtio-pci transport
>> - sdb - virtio-scsi, over virtio-mmio transport
>> - vda - virtio-s
On 01.03.2017 19:44, Daniel P. Berrange wrote:
[...]
replying on the list, a bit lengthy
>
> Ok, my guest has 4 disks
>
> - sda - virtio-scsi, over virtio-pci transport
> - sdb - virtio-scsi, over virtio-mmio transport
> - vda - virtio-scsi, over virtio-pci transport
> - vdb - virtio-scsi, ov
On Wed, Mar 01, 2017 at 07:28:46PM +0100, Viktor Mihajlovski wrote:
> On 01.03.2017 16:58, Daniel P. Berrange wrote:
> > given a basic Fedora 25 guest, with a virtio-mmio disk added as per the
> > guide above...
> >
> > looking at device
> > '/devices/platform/a003e00.virtio_mmio/virtio3/block/
On 01.03.2017 16:58, Daniel P. Berrange wrote:
> On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote:
>> On 01.03.2017 04:30, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote:
One could argue about back-level compatibi
On Wed, Mar 01, 2017 at 03:58:12PM +, Daniel P. Berrange wrote:
> On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote:
> > If wanted, I can take a stab at virtio-mmio, but would need the output
> > of udevadm -a /dev/vda from a virtio-mmio system.
>
> Presumably you mean 'udevad
On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote:
> On 01.03.2017 04:30, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote:
> >> One could argue about back-level compatibility, but virtio by-path
> >> naming has chang
Hello list,
sometimes i have problems rebooting some machine. i think in that cases
shutting down some services fails and machine stays somewhere between
life and death.
Unfortunately my ssh window closes at first and no reconnect is
possible, it only tells "Connection refused".
If this happen
On 02/28/2017 11:11 PM, Mantas Mikulėnas wrote:
With older kernels you'll have to use the older Capabilities= setting
*and* set file capabilities (setcap) on the executable itself.
(Well, depending on what file caps you set you might not even need any
systemd settings at all... See e.g. "getcap
On 01.03.2017 04:30, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote:
>> One could argue about back-level compatibility, but virtio by-path
>> naming has changed multiple times. We have seen virtio-pci-virtio
>> (not predictable),
On Wed, 01.03.17 12:46, Patrik (alab...@gmail.com) wrote:
> So I should just load all units and if reload re-list all units and then
> instead of systemd manager remove Job events and just always check the
> properties all units right???
> THANKS SO MUCH!!
> I got it!
PropertiesChanged messages w
So I should just load all units and if reload re-list all units and then
instead of systemd manager remove Job events and just always check the
properties all units right???
THANKS SO MUCH!!
I got it!
*Patrik*
*GTalk: *alab...@gmail.com
*Web:*
http://www.patrikx3.tk
*Mobile:*
+36 20 342 80
On Wed, 01.03.17 05:11, Mantas Mikulėnas (graw...@gmail.com) wrote:
> CapabilityBoundingSet is the exact opposite of what you need, then. It's
> the *bounding set*, it limits capabilities.
>
> With recent kernels, you'll probably want AmbientCapabilities= as the
> simplest option. (Can't remember
On Wed, 01.03.17 08:41, Patrik Laszlo (alab...@gmail.com) wrote:
>
> *I catch all events:*
>
> UnitNew: 'UnitNew',
> UnitRemoved: 'UnitRemoved',
> JobNew: 'JobNew',
> JobRemoved: 'JobRemoved',
> StartupFinished: 'StartupFinished',
> U
20 matches
Mail list logo
