On Mon, 2022-08-15 at 16:00 +0200, francis.montag...@inria.fr wrote:
> > $ systemctl --user show --property=DefaultTimeoutStopUSec
> > DefaultTimeoutStopUSec=1min 30s
>
> > Aha! Now where do I change that?
>
> Either in:
>
> /usr/lib/systemd/user.conf.d/99-stop-fast.conf
>
On Mon, 2022-08-15 at 10:56 -0600, home user wrote:
> [Patrick]
> > I think I remember that. Be that as it may, this is why I suggest a
> > reinstall might be in order. This is the kind of thing that an
> > update
> > is never going to remove, because some package has been configured
> > to
> >
of them. Are you
> uploading to a server online? Or copying to another partition formatted
> with btrfs?
This command is an Intel NUC on the local network, and /srv/backups is a Btrfs
formatted volume.
$ sudo btrfs send -p home.20220810 home.20220815 | ssh chris@fnuc.local "sudo
btrfs
(responding to 3)
[Patrick; 8/13/2022]
> That's nearly 10 years of updates. Maybe it's time to consider a
> reinstall to get rid of cruft.
On 8/14/22 4:00 AM, Patrick O'Callaghan wrote:
On Sat, 2022-08-13 at 16:40 -0700, Samuel Sieb wrote:
On 8/13/22 07:48, home user wrote:
On 8/12/22 3:37
d size is 30 Gig, and it's not full. There's dar and xar and
> fsarchiver. There's backing up with btrfs too.
I mainly backup just /home because I consider everything else replaceable. So
for that it's
# mount /dev/nvme0n1p5 /mnt ##mount top-level of btrfs
# cd /mnt
# btrfs sub snap -r hom
On Mon, 15 Aug 2022 14:44:43 +0100 Patrick O'Callaghan wrote:
>> Have you checked also for systemctl --user ?
> $ systemctl --user show --property=DefaultTimeoutStopUSec
> DefaultTimeoutStopUSec=1min 30s
> Aha! Now where do I change that?
Either in:
On Mon, 15 Aug 2022 14:44:43 +0100
Patrick O'Callaghan wrote:
> Aha! Now where do I change that?
There is a user.conf file right next to the system.conf file in the
/etc/systemd directory. It has almost all the same parameters, and
I always change both files when changing something to make sure
On Mon, 2022-08-15 at 15:21 +0200, francis.montag...@inria.fr wrote:
>
> On Mon, 15 Aug 2022 12:19:20 +0100 Patrick O'Callaghan wrote:
>
> > This solution has simply stopped working. The default timeout is
> > indeed
> > set as described:
>
> > $ systemctl show --property=DefaultTimeoutStopUSec
On Mon, 15 Aug 2022 12:19:20 +0100 Patrick O'Callaghan wrote:
> This solution has simply stopped working. The default timeout is indeed
> set as described:
> $ systemctl show --property=DefaultTimeoutStopUSec
> DefaultTimeoutStopUSec=5s
Have you checked also for systemctl --user ?
> (note the
Probably not helpful info, but I had dhcpd simply refuse to pay
attention to the signal that was intended to make it cleanly shut down
on a system at work several months ago. I even did enough debugging
to verify the signal was in fact being delivered to the signal handler
in the dhcpd process,
On Mon, 15 Aug 2022 12:19:20 +0100 Patrick O'Callaghan wrote:
> On Sun, 2022-07-17 at 10:27 -0400, Tom Horsley wrote:
>> On Sun, 17 Jul 2022 15:17:56 +0100
>> I made this chage: "DefaultTimeoutStopSec=5s" in both
>> /etc/systemd/system.conf and /etc/systemd/user.conf
> This solution has simply
On Sun, 2022-07-17 at 10:27 -0400, Tom Horsley wrote:
> On Sun, 17 Jul 2022 15:17:56 +0100
> Patrick O'Callaghan wrote:
>
> > OK. Where is that configured (too lazy to look it up :-)?
>
> I made this chage: "DefaultTimeoutStopSec=5s" in both
> /etc/systemd/system.conf and /etc/systemd/user.conf
12 matches
Mail list logo
