On Wed, 29 May 2024 at 11:01, Andreas Svensson
wrote:
>
> Hello,
>
> I have a system that should keep the hardware watchdog active while
> rebooting the system. It has worked fine up to systemd version v254.
>
> I noticed that since systemd version v254 my system stops the hardware
> watchdog afte
On 5/29/24 11:22, Lennart Poettering wrote:
On Mi, 29.05.24 10:51, Andreas Svensson ([email protected]) wrote:
Hello,
I have a system that should keep the hardware watchdog active while
rebooting the system. It has worked fine up to systemd version v254.
I noticed that since systemd v
On Mi, 29.05.24 10:51, Andreas Svensson ([email protected]) wrote:
> Hello,
>
> I have a system that should keep the hardware watchdog active while
> rebooting the system. It has worked fine up to systemd version v254.
>
> I noticed that since systemd version v254 my system stops the hardw
Hello,
I have a system that should keep the hardware watchdog active while
rebooting the system. It has worked fine up to systemd version v254.
I noticed that since systemd version v254 my system stops the hardware
watchdog after systemd-shutdown completes. I think it's the
watchdog_free_dev
On Di, 20.03.18 18:21, Reindl Harald ([email protected]) wrote:
> > > you understand that repsonses like "My problem is sooo important, I need
> > > to
> > > pester the whole systemd-devel mailing list with a regular bug report"
> > > making people trying to help get aware about problems ups
Am 20.03.2018 um 18:13 schrieb Lennart Poettering:
On Di, 20.03.18 18:06, Reindl Harald ([email protected]) wrote:
Am 20.03.2018 um 17:26 schrieb Lennart Poettering:
On Mi, 14.03.18 00:22, Reindl Harald ([email protected]) wrote:
Am 14.03.2018 um 00:00 schrieb Ryan Gonzalez:
You
On Di, 20.03.18 18:06, Reindl Harald ([email protected]) wrote:
>
>
> Am 20.03.2018 um 17:26 schrieb Lennart Poettering:
> > On Mi, 14.03.18 00:22, Reindl Harald ([email protected]) wrote:
> > >
> > > Am 14.03.2018 um 00:00 schrieb Ryan Gonzalez:
> > > > You literally sent this out 1
Am 20.03.2018 um 17:26 schrieb Lennart Poettering:
On Mi, 14.03.18 00:22, Reindl Harald ([email protected]) wrote:
Am 14.03.2018 um 00:00 schrieb Ryan Gonzalez:
You literally sent this out 1 minute after posting the bug. At least
give it time to breath first...
what the hell - sorry f
On Mi, 14.03.18 00:22, Reindl Harald ([email protected]) wrote:
>
>
> Am 14.03.2018 um 00:00 schrieb Ryan Gonzalez:
> > You literally sent this out 1 minute after posting the bug. At least
> > give it time to breath first...
>
> what the hell - sorry for having bad news which i saw from th
Am 14.03.2018 um 00:00 schrieb Ryan Gonzalez:
You literally sent this out 1 minute after posting the bug. At least
give it time to breath first...
what the hell - sorry for having bad news which i saw from the first
reboot of any F27 machine over months thinking others would look at
their s
You literally sent this out 1 minute after posting the bug. At least give
it time to breath first...
On Tue, Mar 13, 2018 at 1:09 PM, Reindl Harald
wrote:
>
>
> Am 13.03.2018 um 19:04 schrieb Michael Biebl:
>
>> My problem is sooo important, I need to pester the whole systemd-devel
>> mailing li
Am 13.03.2018 um 19:04 schrieb Michael Biebl:
My problem is sooo important, I need to pester the whole systemd-devel
mailing list with a regular bug report.
given that in past Fedora releases not a single bug even when there was
a patch upstream got fixed before EOL of the distribution relea
My problem is sooo important, I need to pester the whole systemd-devel
mailing list with a regular bug report.
2018-03-13 16:54 GMT+01:00 Reindl Harald :
> see https://bugzilla.redhat.com/show_bug.cgi?id=1554943 including screenshot
> ___
> systemd-devel
see https://bugzilla.redhat.com/show_bug.cgi?id=1554943 including screenshot
___
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Hi,
I have a general question concerning systemd's behavior during
systemctl reboot, halt or poweroff.
As the system is in the process of shutting down, I am wondering if a
service fails during the shutdown process does systemd still honor the
restart/reboot behavior defined in that programs ser
On Dec 8, 2015 12:13, "Radoslaw Kamil Ejsmont" wrote:
>
> Hi,
>
> I am new to systemd. I am currently running Ubuntu 15.04 with ZFS. I
would like to switch root filesystem to a tmpfs during system shutdown to
reset root ZFS mount point (to dual boot FreeBSD). I have
used /lib/systemd/system-shutdo
Hi,
I am new to systemd. I am currently running Ubuntu 15.04 with ZFS. I would like
to switch root filesystem to a tmpfs during system shutdown to reset root ZFS
mount point (to dual boot FreeBSD). I have used
/lib/systemd/system-shutdown/foo script. I have tried using systemctl
switch-root, b
On 10/07/2015 06:03 PM, Colin Guthrie wrote:
Susant Sahani wrote on 07/10/15 04:05:
On 10/06/2015 06:36 PM, Lennart Poettering wrote:
On Mon, 05.10.15 15:49, Dushyant Uge ([email protected]) wrote:
Hello there,
I have two queries
Some processes terminated immediately after writing re
Susant Sahani wrote on 07/10/15 04:05:
>
>
> On 10/06/2015 06:36 PM, Lennart Poettering wrote:
>> On Mon, 05.10.15 15:49, Dushyant Uge ([email protected]) wrote:
>>
>>> Hello there,
>>>
>>> I have two queries
>>>
>>> Some processes terminated immediately after writing reboot before
>>> reachin
On 10/06/2015 06:36 PM, Lennart Poettering wrote:
On Mon, 05.10.15 15:49, Dushyant Uge ([email protected]) wrote:
Hello there,
I have two queries
Some processes terminated immediately after writing reboot before reaching
systemd unit ExecStop
I am not sure I parse this, but when servic
On Mon, 05.10.15 15:49, Dushyant Uge ([email protected]) wrote:
> Hello there,
>
> I have two queries
>
> Some processes terminated immediately after writing reboot before reaching
> systemd unit ExecStop
I am not sure I parse this, but when services are shut down systemd
won't kill their pr
Hello there,
I have two queries
Some processes terminated immediately after writing reboot before reaching
systemd unit ExecStop
1. which processes are terminated by systemd during early phase of shutdown
?
2. Is this somewhat changeable, configurable?
--
Thanks & Regards,
Dushyant Uge
__
Le mardi 04 février 2014 à 11:31 +0100, Rainer Krienke a écrit :
> Hello,
>
> I am experiencing problems on openSuSE 13.1 systems using systemd, iff
> this system uses NFS mounts for the users home directory mounted by
> automount.
>
> Regular 13.1 installations with local user home directories j
Am 04.02.2014 11:31, schrieb Rainer Krienke:
> I am experiencing problems on openSuSE 13.1 systems using systemd, iff
> this system uses NFS mounts for the users home directory mounted by
> automount.
>
> Regular 13.1 installations with local user home directories just work fine.
>
> The problem
Hello,
I am experiencing problems on openSuSE 13.1 systems using systemd, iff
this system uses NFS mounts for the users home directory mounted by
automount.
Regular 13.1 installations with local user home directories just work fine.
The problem is, that when trying to shut the system down this s
On Sun, 15.09.13 17:26, Koen Kooi ([email protected]) wrote:
> > On Sat, Sep 14, 2013 at 10:52 AM, Koen Kooi
> > wrote:
> >> Please keep in mind that pstore is x86 only. EFI isn't x86 only, but
> >> exceedingly rare outside of that arch.
> >
> > What? Pstore itself isn't. It's a gener
Op 14 sep. 2013, om 11:04 heeft Jan Alexander Steffens
het volgende geschreven:
> On Sat, Sep 14, 2013 at 10:52 AM, Koen Kooi
> wrote:
>> Please keep in mind that pstore is x86 only. EFI isn't x86 only, but
>> exceedingly rare outside of that arch.
>
> What? Pstore itself isn't. It's a gene
On Sat, Sep 14, 2013 at 10:52 AM, Koen Kooi wrote:
> Please keep in mind that pstore is x86 only. EFI isn't x86 only, but
> exceedingly rare outside of that arch.
What? Pstore itself isn't. It's a generic interface to persistent
platform storage. There are backends using EFI variables, NVRAM
(Po
Op 13 sep. 2013, om 00:31 heeft Jan Alexander Steffens
het volgende geschreven:
> On Thu, Sep 12, 2013 at 10:51 PM, Lennart Poettering
> wrote:
>> I think the really late shutdown logs should more liekly end up in some
>> EFI var and then flushed out on next boot or so...
>
> That sounds good
On Fri, Sep 13, 2013 at 04:48:37PM +0100, Colin Guthrie wrote:
> 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 13/09/13 16:33 did
> gyre and gimble:
> > On Fri, Sep 13, 2013 at 08:50:06AM +0100, Colin Guthrie wrote:
> >> 'Twas brillig, and Lennart Poettering at 13/09/13 00:02 did gyre and
> >>
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 13/09/13 16:33 did
gyre and gimble:
> On Fri, Sep 13, 2013 at 08:50:06AM +0100, Colin Guthrie wrote:
>> 'Twas brillig, and Lennart Poettering at 13/09/13 00:02 did gyre and gimble:
>>> On Thu, 12.09.13 23:31, Colin Guthrie ([email protected]) wro
On Fri, Sep 13, 2013 at 08:50:06AM +0100, Colin Guthrie wrote:
> 'Twas brillig, and Lennart Poettering at 13/09/13 00:02 did gyre and gimble:
> > On Thu, 12.09.13 23:31, Colin Guthrie ([email protected]) wrote:
> >
> >>
> >> 'Twas brillig, and Lennart Poettering at 12/09/13 21:51 did gyre and
'Twas brillig, and Lennart Poettering at 13/09/13 00:02 did gyre and gimble:
> On Thu, 12.09.13 23:31, Colin Guthrie ([email protected]) wrote:
>
>>
>> 'Twas brillig, and Lennart Poettering at 12/09/13 21:51 did gyre and gimble:
>>> On Thu, 12.09.13 21:27, Colin Guthrie ([email protected]) w
On Thu, 12.09.13 23:31, Colin Guthrie ([email protected]) wrote:
>
> 'Twas brillig, and Lennart Poettering at 12/09/13 21:51 did gyre and gimble:
> > On Thu, 12.09.13 21:27, Colin Guthrie ([email protected]) wrote:
> >
> >>> So, as mentioned in the other thread, /usr should probably be on
On Fri, 13.09.13 00:31, Jan Alexander Steffens ([email protected]) wrote:
>
> On Thu, Sep 12, 2013 at 10:51 PM, Lennart Poettering
> wrote:
> > I think the really late shutdown logs should more liekly end up in some
> > EFI var and then flushed out on next boot or so...
>
> That sounds goo
'Twas brillig, and Lennart Poettering at 12/09/13 21:51 did gyre and gimble:
> On Thu, 12.09.13 21:27, Colin Guthrie ([email protected]) wrote:
>
>>> So, as mentioned in the other thread, /usr should probably be on some
>>> "OS resource blacklist" or so, and not attempted to be shutdown.
>>>
>>
On Thu, Sep 12, 2013 at 10:51 PM, Lennart Poettering
wrote:
> I think the really late shutdown logs should more liekly end up in some
> EFI var and then flushed out on next boot or so...
That sounds good. Maybe use the pstore system? A service could then
read that data into the journal at boot, a
On Sat, 20.07.13 18:50, Colin Walters ([email protected]) wrote:
Heya,
> So OSTree sets up systemd inside a chroot - /usr is a read-only bind
> mount, and /var is a bind mount outside the root to a shared location.
> Furthermore, /sysroot points to the real root.
>
> Since last time we discusse
On Thu, 12.09.13 21:27, Colin Guthrie ([email protected]) wrote:
> > So, as mentioned in the other thread, /usr should probably be on some
> > "OS resource blacklist" or so, and not attempted to be shutdown.
> >
> > But unmounting /var during shutdown should actually work. The only thing
> > t
'Twas brillig, and Lennart Poettering at 12/09/13 17:43 did gyre and gimble:
> On Sat, 20.07.13 18:50, Colin Walters ([email protected]) wrote:
>
> Heya,
>
>> So OSTree sets up systemd inside a chroot - /usr is a read-only bind
>> mount, and /var is a bind mount outside the root to a shared loca
On Sat, Jul 20, 2013 at 06:50:13PM -0400, Colin Walters wrote:
> So OSTree sets up systemd inside a chroot - /usr is a read-only bind
> mount, and /var is a bind mount outside the root to a shared location.
> Furthermore, /sysroot points to the real root.
>
> Since last time we discussed this:
> h
'Twas brillig, and Colin Walters at 20/07/13 23:50 did gyre and gimble:
> So OSTree sets up systemd inside a chroot - /usr is a read-only bind
> mount, and /var is a bind mount outside the root to a shared location.
> Furthermore, /sysroot points to the real root.
>
> Since last time we discussed
So OSTree sets up systemd inside a chroot - /usr is a read-only bind
mount, and /var is a bind mount outside the root to a shared location.
Furthermore, /sysroot points to the real root.
Since last time we discussed this:
http://lists.freedesktop.org/archives/systemd-devel/2012-September/006668.ht
On Tue, 11.06.13 10:07, Umut Tezduyar ([email protected]) wrote:
> Hi,
>
> Those 2 lines were added on 89b1d5e0e49d3b3501e5f3aadcad712290bcd9bf and
> the commit log explains why we needed them. "/" can be treated as special
> case and excluded.
Just for completeness' sake. This was implemented i
On Tue, Jun 11, 2013 at 10:59:42AM +0200, Thomas Bächler wrote:
> Am 11.06.2013 10:34, schrieb Colin Guthrie:
> > Without reading the code etc., I'm running systemd with that commit
> > (v204) and I don't get any conflicts for my -.mount unit...
> >
> > So it seems that code is not run for me for
On Tue, Jun 11, 2013 at 10:59 AM, Thomas Bächler wrote:
> I think this code is only called when there is no -.mount unit, which
> results from a missing entry for / in fstab. It is entirely possible
> that Ross didn't add / to his fstab by accident or on purpose.
I just want to point out: This is
Am 11.06.2013 10:34, schrieb Colin Guthrie:
> Without reading the code etc., I'm running systemd with that commit
> (v204) and I don't get any conflicts for my -.mount unit...
>
> So it seems that code is not run for me for whatever reason.
>
> After a very quick glance at the code, it could just
On Tue, Jun 11, 2013 at 10:07 AM, Umut Tezduyar wrote:
> Those 2 lines were added on 89b1d5e0e49d3b3501e5f3aadcad712290bcd9bf and the
> commit log explains why we needed them. "/" can be treated as special case
> and excluded.
If so, I guess also /usr and anything marked x-initrd.mount should be
'Twas brillig, and Ross Lagerwall at 11/06/13 08:19 did gyre and gimble:
> On Mon, Jun 10, 2013 at 08:30:40PM +0200, Lennart Poettering wrote:
>> Hmm, this is certainly weird. normally -.mount should not have any such
>> conflicts. I really wonder where you got those from... What is the
>> contents
Hi,
Those 2 lines were added on 89b1d5e0e49d3b3501e5f3aadcad712290bcd9bf and
the commit log explains why we needed them. "/" can be treated as special
case and excluded.
Thanks.
On Tue, Jun 11, 2013 at 9:19 AM, Ross Lagerwall wrote:
> On Mon, Jun 10, 2013 at 08:30:40PM +0200, Lennart Poetterin
On Mon, Jun 10, 2013 at 08:30:40PM +0200, Lennart Poettering wrote:
> Hmm, this is certainly weird. normally -.mount should not have any such
> conflicts. I really wonder where you got those from... What is the
> contents of /run/systemd/generator/-.mount for you?
>
AFAICT, mount_load_proc_self_m
On Mon, Jun 10, 2013 at 08:30:40PM +0200, Lennart Poettering wrote:
> > As root: halt
> >
> > I have attached the output of "systemctl show -- -.mount" and /etc/fstab
> > and /proc/cmdline.
> >
> > I see that Conflicts=umount.target is set, though I have no idea why.
> >
> > I haven't changed to
On Mon, 10.06.13 14:10, Ross Lagerwall ([email protected]) wrote:
> On Mon, Jun 10, 2013 at 12:33:01PM +0200, Lennart Poettering wrote:
> > This is really weird... (Though unrelated to systemd-shutdown, as this
> > is generated before we execute it, replacing PID 1).
> >
> > -.mount is the
On Mon, Jun 10, 2013 at 12:33:01PM +0200, Lennart Poettering wrote:
> This is really weird... (Though unrelated to systemd-shutdown, as this
> is generated before we execute it, replacing PID 1).
>
> -.mount is the mount unit is something we do not try to unmount at
> shutdown from normal systemd,
On Sun, 09.06.13 17:11, Zbigniew Jędrzejewski-Szmek ([email protected]) wrote:
> > And if I run "pacman -S glibc" and then shutdown:
> > -.mount mount process exited, code=exited status=32
> > -.mount changed unmounting -> mounted
> > Job -.mount/stop finished, result=failed
> > Failed unmounting
On Sun, Jun 09, 2013 at 05:11:19PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Jun 09, 2013 at 08:52:01AM +0100, Ross Lagerwall wrote:
> > On Sat, Jun 08, 2013 at 05:06:50PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > > Maybe mention that systemd-shutdown is statically linked (I know it
>
On Sun, Jun 09, 2013 at 08:52:01AM +0100, Ross Lagerwall wrote:
> On Sat, Jun 08, 2013 at 05:06:50PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > Maybe mention that systemd-shutdown is statically linked (I know it
> > can be inferred from the text, but being explicit might be better).
>
> At leas
On Sat, Jun 08, 2013 at 05:06:50PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> Maybe mention that systemd-shutdown is statically linked (I know it
> can be inferred from the text, but being explicit might be better).
At least on Arch, it is still statically linked to libc and udev:
$ ldd /usr/lib/
Obligatory RTFM comment:
http://freedesktop.org/wiki/Software/systemd/Debugging#Diagnosing_Shutdown_Problems
and other assorted reading material
http://www.freedesktop.org/wiki/Software/systemd
On Wed, Sep 19, 2012 at 2:03 PM, Mr Green wrote:
> Hi,
>
> Currently testing a service that requires sy
Hi,
Currently testing a service that requires syncing before system
shutdown, at the moment it is not working. Systemd is simply shutting
down before running the script. Is there any way to test that script is
being run at poweroff?
MrG
___
systemd
60 matches
Mail list logo
