On Mon, 16 Mar 2020, Mantas Mikulėnas wrote:
On Mon, Mar 16, 2020 at 11:52 AM Thomas Blume wrote:
On Fri, 13 Mar 2020, Alexander E. Patrakov wrote:
> On Fri, Mar 13, 2020 at 7:07 PM Andrei Borzenkov
wrote:
>
>> And what is the "official" way to
On Fri, 13 Mar 2020, Alexander E. Patrakov wrote:
On Fri, Mar 13, 2020 at 7:07 PM Andrei Borzenkov wrote:
And what is the "official" way to prevent various units required by root
mount from being stopped during shutdown? There could be arbitrarily
deep stack (NIC - iSCSI - multipath - raid -
root is already mounted in the initrd
and has no more relevance after switch root.
It could be even dangerous, because on shutdown the system root mount might be
attempted to stop before the system is switching back to the initrd.
Is _netdev applicable for the system root mount at all?
Regards
Tho
On Dienstag 2018-10-02 17:27, Lennart Poettering wrote:
On Di, 02.10.18 16:44, Thomas Blume (thomas.bl...@suse.com) wrote:
On Dienstag 2018-10-02 16:17, Lennart Poettering wrote:
Not sure I follow. System users should have a UID below 1000 (or
whatever your OS defines as boundary between
On Dienstag 2018-10-02 16:17, Lennart Poettering wrote:
Not sure I follow. System users should have a UID below 1000 (or
whatever your OS defines as boundary between system and regular
users).
Sure, but even UID 0 would be still amongst the user.slice and get the
user restrictions, right?
Hi,
there is some large software like SAP or Oracle out there that need to
be started/stopped via special users.
At system boot, they get started via a user session and inherit the
restrictions from the user slice.
That is not really appropriate for such large processes as they usually
need
rule should consider this.
Thomas Blume
--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
Maxfeldstr. 5 / D-90409 Nürnberg / Phone: +49-911-740 53 - 0 / VOIP: 3919
GPG 2048R/2CD4D3E8 9A50 048F 1C73 59AA 4D2E 424E B3C6 3FD9 2CD4
RDEVS; do
[[ "$WAKEUPDEVS" =~ ${otherdev%/power/wakeup} ]] || WAKEUPDEVS+="$otherdev
";
done
[[ "$WAKEUPDEVS" =~ "$1/power/wakeup" ]] && echo "RESUME_FROM_IDLE=1"
--<
Regards
Thomas Blume
--
SUSE Linux GmbH, GF:
On Wed, 24 Jan 2018, Lennart Poettering wrote:
You cannot lock device that does not exist. And as soon as it appears it
is mounted.
hu? Thomas' proposed approach of "systemctl lock $DEVICE" also requires there
to be a known path for a device, hence it must already be plugged in
already?
Not
On Tue, 23 Jan 2018, Simon McVittie wrote:
I'm not sure why the old behavior is not compatible with modern
storage
The traditional behaviour requires you to have a well-defined point during
boot at which you know that all hardware that was attached at power-on has
been detected, and all
systemctl daemon-reload should also update the manager defaults from
/etc/systemd/system.conf.
For details, see:
http://lists.freedesktop.org/archives/systemd-devel/2015-June/033062.html
Regards
Thomas Blume
--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham
, and correcting it later. I will add that to the TODO list.
Ah ok, I thought it was intended that daemon-reload doesn't reload system.conf.
I will try to provide a new patch.
Thanks
Thomas Blume
--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham
Norton, HRB 21284 (AG
for the manager clients and that for reloading the manager
configuration, daemon-reexec must be used.
Regards
Thomas Blume
--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham
Norton, HRB 21284 (AG Nürnberg)
Maxfeldstr. 5 / D-90409 Nürnberg / Phone: +49-911-740 53 - 0
On Donnerstag 2015-01-08 21:29, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jan 08, 2015 at 01:37:57PM +0100, Thomas Blume wrote:
Currently, systemd can only ignore files specified by their path, during
tmpdir cleanup. This patch adds the feature to give usernames as argument.
During cleanup
/* - - - - testuser3,testuser2
in order to prevent all files belonging to testuser2 and testuser3 from being
deleted in /tmp.
This feature has been available in SystemV systems.
Would be good to also have it in systemd systems.
Regards
Thomas Blume
--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane
On Fri, 18 Jul 2014, Dan Horák wrote:
On Fri, 18 Jul 2014 13:42:21 +0200 (CEST)
Thomas Blume thomas.bl...@suse.com wrote:
Ok, thanks for the input.
Attached is the new patch.
Thomas, do you know whether the VM00 info always refer to the top-level
virt, where the Linux guest runs? I've
then inhibit the suspend if there was no previous lid open event or
allow it without timeout, if there was one.
I'm attaching a little example patch to visualize my approach.
Any comment is appreciated.
Regards
Thomas Blume
--
SUSE LINUX Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
On Fri, 4 Jul 2014, Lennart Poettering wrote:
+_id = PR/SM;
+r = 1;
Well, this is not useful, this is about detecting whether the OS we run
in is the closest to the hardware of the system or is is removed from it
via some virtualization layer.
This definition means that on
On Fri, 4 Jul 2014, Dan Horák wrote:
On Fri, 4 Jul 2014 15:07:18 +0200 (CEST)
Thomas Blume thomas.bl...@suse.com wrote:
systemd was lacking the code to detect virtualization on s390x.
The patch adds detection for the primary virtualization layer (PR/SM)
as well as for secondary layers (z/VM
On Fri, 4 Jul 2014, Zbigniew Jędrzejewski-Szmek wrote:
+#if defined(__s390x__)
+/* First layer virtualization (PR/SM) is always present on s390x */
+_id = PR/SM;
+r = 1;
What does this mean? Is it like XEN dom0, i.e. normianally a virtuallized OS,
but one that has full
On Mon, 7 Jul 2014, Lennart Poettering wrote:
Actually it is like there is no dom0 on s390(x).
Direct hardware access is done on a level where the operating system doesn't
have any influence.
For example, unlike Xen dom0, the disks are never physical devices, they are
only shares of a storage
On Mon, 7 Jul 2014, Lennart Poettering wrote:
For the test, e.g. ConditionVirtualization, there would be no difference.
I only distinguished this in order to have systemd-detect-virt showing the
correct virtualization technology.
Sure we could cover everything under something like, e.g. s390
On Mon, 7 Jul 2014, Lennart Poettering wrote:
IMHO the main difference is the level of maturity.
z/VM is about 30 years old and has a huge amount of tools for everything you
could imagine. KVM is relatively new and under heavy development.
Furthermore, KVM is bound to the linux kernel, while
;
+break;
+}
+}
+}
+
+goto finish;
+#endif
+
/* this will set _id to other and return 0 for unknown hypervisors */
r = detect_vm_cpuid(_id);
if (r != 0)
--
1.8.4.5
Thomas Blume
--
SUSE LINUX Products GmbH
24 matches
Mail list logo
