On Sun, Sep 18, 2016 at 9:58 AM, François Patte
> Le 17/09/2016 22:53, Jon LaBadie a écrit :
>> On Sat, Sep 17, 2016 at 11:34:54AM -0500, Rex Dieter wrote:
>>> Tom Horsley wrote:
>>>> Because systemd has a gazillion bugs like this
>>> In cases like this in general, it's not systemd,
>>> but the individual services that have bugs.
>> Does anyone else tire of hearing
>> "its not systemd, its ..."
> I have no idea about this and systemd in general.... I have four
> computers running under fedora systemd: a desktop under f21, no problem
> of the like; sometimes I get this message: "a start job is running"
> about some partitions installed on two disks in a raid-1 array, that I
> added to the main system after the install. I suspect that it is an fsck
> check but, systemd gives no info on the boot screen about this and I did
> not check in the huge journal...
> two laptops under f23 with no problems abo some running jobs (start or stop)
> and one laptop under f24 which has these problems. What can we say?
> there are bugs in fc 24 installation of systemd? These stop problems can
> come from the way journalctl write in the /var partition: both partition
> /var and /usr fail to be unmounted at shutdown (they are separate
> partitions from /), is it because journalctl wants to write the logs
> until the last second and the shutdown process wants to umount these two
> partitions too earlier? I am not able to answer and solve these
> problems... But are they systemd problems or a fedora configuration of
> systemd problem?
> Who knows?
The problem is there is some process in the user session that isn't
quitting, and systemd doesn't force quit it for 1m30s at which time it
obliterates the user session and everything running in it. You can use
loginctl to list the contents of the user session, but in my
experience I often can't get to a different tty to check on this.
You can try one of two things:
1. Log out, then restart or shutdown. For whatever reason this works
for me maybe 1/2 the time or more.
2. Edit /etc/systemd/logind.conf such that
i.e. remove the # that's currently there by default. This was slated
to be the default for Fedora 25 but the feature has other
consequences, namely it would kill screen and tmux in your user
session also and so there are some unfinished work arounds to make
those things use different scopes or sessions or whatever they're
Just realize with this option set to use, literally everything running
in your user session will get killed off. There is a way to use
systemd-run blah blah you'll have to read about it, to launch tmux in
a different session that doesn't get killed off. I have no idea how
you reconnect to it, if anything else is different other than just
running it that way because I haven't tried it. I have found some
other things like btrfs balance and scrub, which can take hours or
days, will get killed off also and I'm working with upstream Btrfs
folks on a work around for that also, because the real work is done by
the kernel so the operation isn't killed so much as the user process.
So the user process needs to be killable and then able to reconnect to
check status, pause or cancel correctly.
users mailing list -- firstname.lastname@example.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org