RE: apt cache full, mandb update failed

[Bonno Bloksma]

Hi Brian,

>> This morning I wanted to do an apt-get update / upgrade cycle on my 
>> system.  The update went ok, but during the upgrade I got a " No space 
>> left on device" warning.
>> [...]
>> Preparing to replace ssh 1:6.0p1-4+deb7u3 (using 
>> .../ssh_1%3a6.0p1-4+deb7u4_all.deb) ...
>> Unpacking replacement ssh ...
>> Processing triggers for man-db ...
>> /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on 
>> device Processing triggers for hicolor-icon-theme ...
>> Processing triggers for mime-support ...
>> [...]
>> 
>> My /var partition had filled up, it seems out of the 3GB there was 
>> about 2.5GB in /var/cache/apt/archives.  The solution was simple, just 
>> an apt-get autoclean, I now have 2.2GB free on my /var partition. ;-)
>> 
>> But. What wanted apt write to that mandb and was that important?
>
> Apt calls dpkg and it is during the course of installing with dpkg that the 
> triggering process occurs. You can see this by doing
> 
>   dpkg -i /var/cache/apt/archives//openssh-server_1%3a6.0p1-4+deb7u4_i386.deb

Just did that again and it completed normaly. That is what I needed to know, 
now I know the mandb is up2date as well.
Thanks.

>>   /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on 
>> device Was that that man page for ssh or something like that?
>
> Yes. mandb has an interest in what happens in /usr/share/man. Changes there 
> lead to its updating its database.
> For reasons you give it didn't happen, so dpkg issues a *warning*.
> Nothing too serious to stop the unpacking and setting up of all the updated 
> packages.

Well a disk full warning is pretty serious. But I get what you mean, a warning 
from mandb maintenance itself is not serious enough, just the reason why that 
happened.

>> After cleaning up I did another apt-get upgrade but it reported 
>> nothing to do.
>
> This is to be expected, surely. All packages are at their newest versions.

I had hoped the failed mandb update would register somewhere and a second 
attempt to "upgrade" would fix it.
Turns out I needed that dpkg line to do that.

>> So if it failed to update some files why did it 
>> complete anyhow?
> 
> Would you rather the upgrade came to a halt because of some relatively minor 
> issue?

Yes and no, according to apt-get it was a minor issue of a mandb update, the 
roor cause was a majot issue.
>
>  apt-get --reinstall install openssh-server
> 
> could be run after space is freed up.

I did it by running the dpkg line, same end result I guess.
Thank for the explanation and help fixing it.

Bonno Bloksma

Re: on-demand mounting of filesystems via Systemd (e.g. /backup)

[Michael Biebl]

Am 20.04.2016 um 23:19 schrieb Ansgar Burchardt:
> I'm not sure you can achieve this via systemd's .mount units, although
> systemd itself also makes use of mount namespaces.  For example, systemd
> uses them to provide a per-service /tmp, make /home unaccessible or only
> allowing read-only access to /usr or /etc for individual service.  See
> the PrivateTmp=, ProtectHome=, ProtectSystem=, PrivateDevices=,
> ReadOnlyDirectories=, InaccessibleDirectories= and ReadWriteDirectories=
> in man:systemd.exec(5).

If you run the backup via a .service file, you could use
MountFlags=private, see

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#MountFlags=
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: on-demand mounting of filesystems via Systemd (e.g. /backup)

[Jonathan Dowland]

On Wed, Apr 20, 2016 at 11:19:46PM +0200, Ansgar Burchardt wrote:
> I think using mount namespaces is a bit nicer solution for the problem:
...
> I'm not sure you can achieve this via systemd's .mount units, although
> systemd itself also makes use of mount namespaces.  For example, systemd
> uses them to provide a per-service /tmp, make /home unaccessible or only
> allowing read-only access to /usr or /etc for individual service.  See
> the PrivateTmp=, ProtectHome=, ProtectSystem=, PrivateDevices=,
> ReadOnlyDirectories=, InaccessibleDirectories= and ReadWriteDirectories=
> in man:systemd.exec(5).

Thanks, that does look useful. I will look into this some more.

Re: on-demand mounting of filesystems via Systemd (e.g. /backup)

[Ansgar Burchardt]

Hi,

Jonathan Dowland writes:
> I just wrote a blog post about how to use Systemd to configure mount-on-demand
> filesystems, e.g. /backup (in my case). This was triggered by recent news in
> the UK that a major hosting provider had deleted all their customer VMs by
> accident by issuing something like "rm -rf" - but they *also* got all their
> backups because their backup volume was mounted too.
>
> Anyway, in the past I've read some useful tips for using Systemd on this
> list, so here's the blog post should it be of any interest:
>
> https://jmtd.net/log/mount_on_demand_backups/

I think using mount namespaces is a bit nicer solution for the problem:
the /backup mount will only be visible for the backup process and, as
far as I understand, be automatically unmounted when all processes in
the namespace exit, i.e. when the backup is done.

Here is a quick example in an interactive shell:

+---
| # umount /boot; ls /boot
| [empty]
| # unshare -m
| [Note: This will start a subshell]
| # mount /boot; ls /boot
| System.map-4.3.0-1-amd64 [...]
| [Run backup here ;)]
| [Note: /boot will appear empty for other processes at this point.]
| # exit
| # ls /boot
| [empty]
+---

I used /boot instead of /backup as that exists on my computer.

Note that /boot is only visible from the subshell started by unshare or
other processes that entered the namespace (e.g. with nsenter(1)).  A
stray `rm -rf /` can thus not see it even when run at the time of the
backup.

I'm not sure you can achieve this via systemd's .mount units, although
systemd itself also makes use of mount namespaces.  For example, systemd
uses them to provide a per-service /tmp, make /home unaccessible or only
allowing read-only access to /usr or /etc for individual service.  See
the PrivateTmp=, ProtectHome=, ProtectSystem=, PrivateDevices=,
ReadOnlyDirectories=, InaccessibleDirectories= and ReadWriteDirectories=
in man:systemd.exec(5).

Ansgar

Re: on-demand mounting of filesystems via Systemd (e.g. /backup)

[Jonathan Dowland]

On Wed, Apr 20, 2016 at 09:40:40PM +0200, Jochen Spieker wrote:
> Did you edit your blog post afterwards or did I just skim over your own
> rebuttal of the story? :)

No I named it as a hoax from the off -- the tell for me was that one of the
replies to the hoax post was a suggestion to use dd(1) for recovery, and the
OP replied "I've swapped the arguments if= and of=. What do I do now?" That
stretched credulity too much for me.

On the other hand, 123-reg really did do this!

Re: on-demand mounting of filesystems via Systemd (e.g. /backup)

[Jonathan Dowland]

On Wed, Apr 20, 2016 at 01:44:07PM -0600, John L. Ries wrote:
> >Thanks! I think we need to share more examples on how to use systemd
> >properly. A lot of the criticism stems from the simple fact that people
> >just need to learn what the new tools can do for them.
> 
> That would be an indication that systemd is non-intuitive and poorly
> documented, which has been my impression for the past several years.

That may be, and I've listed several opinions of mine as to ways systemd
could improve for this specific case, in the blog post. However, I have
yet to see a solution to do what I just did with bog-standard shellscripts
or whatever which is clearer or conciser than this solution, despite the
niggles.


-- 
Jonathan Dowland

Re: Installing tt-rss

[Rainer Dorsch]

Hi Sebastian,

On Tuesday 19 April 2016 03:58:02 Sebastian Reichel wrote:
> Hi,
> 
> On Mon, Apr 18, 2016 at 10:42:54PM +0200, Rainer Dorsch wrote:
> > On Monday 18 April 2016 18:20:19 Sebastian Reichel wrote:
> > > On Sat, Apr 16, 2016 at 03:30:30PM +0200, Rainer Dorsch wrote:
> > > > I tried to install tt-rss on a stretch system. During the
> > > > configuration of
> > > > tt- rss, debconf asks for a username and a password confirmation for
> > > > the
> > > > tt-rss database ... but it never asked for the password itself.
> > > > 
> > > > /usr/share/doc/tt-rss/README.* does also not give more insight.
> > > > 
> > > > Did anybody manage to setup tt-rss using the debconf and
> > > > dbconfig-common ?
> > > 
> > > Are you sure, that you did not accidently skip the password
> > > question?
> > 
> > HmmmI tried again (not sure if dbconfig keeps somewhare some config):
> > 
> > I noticed
> > /var/lib/dpkg/info/tt-rss.prerm: 32: [: =: unexpected operator
> > not sure if it does any harm.
> 
> Interesting. That should not happen.
> 
> > When running
> > 
> > root@scw:/etc# apt-get install tt-rss
> > 
> > I get these questions
> > 
> > 
> > Configure database for tt-rss with dbconfig-common? 
> > 
> > Host name of the  database server for tt-rss: localhost
> > 
> > Port number for the  service: 
> > 
> > database name for tt-rss: ttrss_
> > 
> > storage directory for tt-rss:-- I hope there is a sensible
> > default
> > 
> > username for tt-rss: ttrss
> > 
> > Password confirmation: ???
> 
> Ok. I think it's a bug in tt-rss due to changes in dbconfig-common
> introduced in version 2.0. Can you try installing dbconfig-mysql or
> dbconfig-pgsql (depending on which database type you want) before
> installing tt-rss?

Installing dbconfig-mysql changed the behavior. Now debconf asks for passwd 
for the mysql root and tt-rss user. But I end up with another error:

  ┌┤ 
Configuring tt-rss ├─┐  

  │ An error occurred while installing the database:
  
│  
  │ 
  
│  
  │ ERROR 2002 (HY000): Can't connect to local MySQL server 
through socket '/var/run/mysqld/mysqld.sock' (2) . Your options are:  │ 
 
  │  * abort - Causes the operation to fail; you will need to 
downgrade,  │   
   
  │reinstall, reconfigure this package, or otherwise manually 
intervene   │  
  │to continue using it. This will usually also impact your 
ability to│ 
 
  │install other packages until the installation failure is 
resolved. │ 
 
  │  * retry - Prompts once more with all the configuration 
questions │ 
 
  │(including ones you may have missed due to the debconf 
priority│   
   
  │setting) and makes another attempt at performing the 
operation.│ 
 
  │  * retry (skip questions) - Immediately attempts the operation 
again, │  
  │skipping all questions. This is normally useful only if you 
have   │  
  │solved the underlying problem since the time the error 
occurred.   │   
   
  │  * ignore - Continues the operation ignoring dbconfig-common 
errors.  │  
  │This will usually leave this package without a functional 
database.│  
  │ 
  
│  
  │ Next step for database installation:
  
│  
  │ 
  
│  
  │abor

Re: on-demand mounting of filesystems via Systemd (e.g. /backup)

[John L. Ries]

Thanks! I think we need to share more examples on how to use systemd
properly. A lot of the criticism stems from the simple fact that people
just need to learn what the new tools can do for them.


That would be an indication that systemd is non-intuitive and poorly 
documented, which has been my impression for the past several years. 
There may be no good cure for the former (but a better systemadm would 
help), but there is for the latter.


--|
John L. Ries  |
Salford Systems   |
Phone: (619)543-8880 x107 |
or (435)867-8885  |
--|


On Wed, 20 Apr 2016, Jochen Spieker wrote:


Jonathan Dowland:


I just wrote a blog post about how to use Systemd to configure mount-on-demand
filesystems, e.g. /backup (in my case). This was triggered by recent news in
the UK that a major hosting provider had deleted all their customer VMs by
accident by issuing something like "rm -rf" - but they *also* got all their
backups because their backup volume was mounted too.


That was a marketing hoax (which I didn't even find really credible
because Linux' rm doesn't operate recursively on / without the option
--no-preserve-root for some years now).


Anyway, in the past I've read some useful tips for using Systemd on this
list, so here's the blog post should it be of any interest:

https://jmtd.net/log/mount_on_demand_backups/


Thanks! I think we need to share more examples on how to use systemd
properly. A lot of the criticism stems from the simple fact that people
just need to learn what the new tools can do for them.

J.
--
If I had to live on a desert island I would take a mobile phone,
preferably a Nokia 8810.
[Agree]   [Disagree]

Re: on-demand mounting of filesystems via Systemd (e.g. /backup)

[Jochen Spieker]

Jochen Spieker:
> Jonathan Dowland:
>> 
>> I just wrote a blog post about how to use Systemd to configure 
>> mount-on-demand
>> filesystems, e.g. /backup (in my case). This was triggered by recent news in
>> the UK that a major hosting provider had deleted all their customer VMs by
>> accident by issuing something like "rm -rf" - but they *also* got all their
>> backups because their backup volume was mounted too.
> 
> That was a marketing hoax

Did you edit your blog post afterwards or did I just skim over your own
rebuttal of the story? :)

J.
-- 
I cannot comprehend the idea of chemical and biological weapons.
[Agree]   [Disagree]
 


signature.asc
Description: Digital signature

Re: on-demand mounting of filesystems via Systemd (e.g. /backup)

[Jochen Spieker]

Jonathan Dowland:
> 
> I just wrote a blog post about how to use Systemd to configure mount-on-demand
> filesystems, e.g. /backup (in my case). This was triggered by recent news in
> the UK that a major hosting provider had deleted all their customer VMs by
> accident by issuing something like "rm -rf" - but they *also* got all their
> backups because their backup volume was mounted too.

That was a marketing hoax (which I didn't even find really credible
because Linux' rm doesn't operate recursively on / without the option
--no-preserve-root for some years now).

> Anyway, in the past I've read some useful tips for using Systemd on this
> list, so here's the blog post should it be of any interest:
> 
> https://jmtd.net/log/mount_on_demand_backups/

Thanks! I think we need to share more examples on how to use systemd
properly. A lot of the criticism stems from the simple fact that people
just need to learn what the new tools can do for them.

J.
-- 
If I had to live on a desert island I would take a mobile phone,
preferably a Nokia 8810.
[Agree]   [Disagree]
 


signature.asc
Description: Digital signature

Stretch/Sid not resuming from suspend

[Lucio Crusca]

Hello *,

I'm using Stretch/Sid amd64 and I update it every few days. Since about 
a month or so it fails to resume from suspend to RAM. It doesn't happen 
regularly, it fails about 50% of the times. When it doesn't resume, I 
get only a black screen in text mode with the blinking caret in the top 
left corner of the screen. No keyboard input is working.
I'm using Xfce and I suspend always by hand using the menu. My kernel is 
4.4.0-1-amd64 with nvidia legacy driver (340). I'm not sure but I seem 
to recall the problem started when my driver moved from nvidia to 
nvidia-legacy. Or, maybe, it started with some kernel update, but I 
don't know which one.


I'd try with the nouveau driver but it proved to be even less reliable 
than the nvidia, causing freezes also during normal use of the system. 
The hardware is a Intel Core I5 notebook (Dell Precision M4500).


What can I do to pin down the issue?

Re: apt cache full, mandb update failed

[Brian]

On Wed 20 Apr 2016 at 06:52:22 +, Bonno Bloksma wrote:

> This morning I wanted to do an apt-get update / upgrade cycle on my
> system.  The update went ok, but during the upgrade I got a " No space
> left on device" warning.
> [...]
> Preparing to replace ssh 1:6.0p1-4+deb7u3 (using 
> .../ssh_1%3a6.0p1-4+deb7u4_all.deb) ...
> Unpacking replacement ssh ...
> Processing triggers for man-db ...
> /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on device
> Processing triggers for hicolor-icon-theme ...
> Processing triggers for mime-support ...
> [...]
> 
> My /var partition had filled up, it seems out of the 3GB there was
> about 2.5GB in /var/cache/apt/archives.  The solution was simple, just
> an apt-get autoclean, I now have 2.2GB free on my /var partition. ;-)
> 
> But. What wanted apt write to that mandb and was that important?

Apt calls dpkg and it is during the course of installing with dpkg that
the triggering process occurs. You can see this by doing

  dpkg -i /var/cache/apt/archives//openssh-server_1%3a6.0p1-4+deb7u4_i386.deb
 
>   /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on device
> Was that that man page for ssh or something like that?

Yes. mandb has an interest in what happens in /usr/share/man. Changes
there lead to its updating its database. For reasons you give it didn't
happen, so dpkg issues a *warning*. Nothing too serious to stop the
unpacking and setting up of all the updated packages.

> After cleaning up I did another apt-get upgrade but it reported
> nothing to do.

This is to be expected, surely. All packages are at their newest
versions.

> So if it failed to update some files why did it
> complete anyhow?

Would you rather the upgrade came to a halt because of some relatively
minor issue?

  apt-get --reinstall install openssh-server

could be run after space is freed up.

on-demand mounting of filesystems via Systemd (e.g. /backup)

[Jonathan Dowland]

I just wrote a blog post about how to use Systemd to configure mount-on-demand
filesystems, e.g. /backup (in my case). This was triggered by recent news in
the UK that a major hosting provider had deleted all their customer VMs by
accident by issuing something like "rm -rf" - but they *also* got all their
backups because their backup volume was mounted too.

Anyway, in the past I've read some useful tips for using Systemd on this
list, so here's the blog post should it be of any interest:

https://jmtd.net/log/mount_on_demand_backups/

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Re: Beginning of the End for Wheezy [sigh!]

[Patrick Bartek]

On Tue, 19 Apr 2016, Jimmy Johnson wrote:

> On 04/19/2016 12:49 PM, Jimmy Johnson wrote:
> > On 04/16/2016 03:27 PM, Patrick Bartek wrote:
> >>
> >> Much to my regret (and others, too, I'm sure), yesterday, on 15
> >> April 2016, the beginning of the end began for Wheezy. Google, as
> >> announced months ago, finally ceased support for its browser on
> >> Wheezy.  I double checked just to be sure, and in the course of
> >> that check also discovered "official" Debian support for Wheezy
> >> will cease in a little over a week on 26 April 2016 -- just 3
> >> years after its release. However, it will automatically enter LTS
> >> until 2018 at which time all support ceases and EOL "officially"
> >> occurs.
> >>
> >> Well, at least I have time to look for an alternative. Maybe,
> >> Devuan will be viable by then, but I doubt it.  Or Debian will
> >> offer a choice of inits as a standard option during installs on
> >> future releases, but I very much doubt it.
> >>
> >> B
> >
> > Ubuntu using upstart,
> > trusty   14.04 LTS Release Date 2014-04-17 End Of Life 2019-04
> > precise  12.04 LTS Release Date 2012-04-26 End Of Life 2017-04
> 
> Some other systems to look at are, Kali Linux https://www.kali.org/ - 
> EXE GNU/Linux http://exegnulinux.net/ - Q40S http://q4os.org/ I have 
> them all installed.  Some of these are built from bootstrap and are
> not remasters of other systems, all are ".deb" systems.

Thanks.  I'll take a look.

B

Re: Beginning of the End for Wheezy [sigh!]

[Patrick Bartek]

On Tue, 19 Apr 2016, Jimmy Johnson wrote:

> On 04/16/2016 03:27 PM, Patrick Bartek wrote:
> >
> > Much to my regret (and others, too, I'm sure), yesterday, on 15
> > April 2016, the beginning of the end began for Wheezy. Google, as
> > announced months ago, finally ceased support for its browser on
> > Wheezy.  I double checked just to be sure, and in the course of
> > that check also discovered "official" Debian support for Wheezy
> > will cease in a little over a week on 26 April 2016 -- just 3 years
> > after its release.  However, it will automatically enter LTS until
> > 2018 at which time all support ceases and EOL "officially" occurs.
> >
> > Well, at least I have time to look for an alternative. Maybe,
> > Devuan will be viable by then, but I doubt it.  Or Debian will
> > offer a choice of inits as a standard option during installs on
> > future releases, but I very much doubt it.
> >
> > B
> 
> Ubuntu using upstart,
> trusty   14.04 LTS Release Date 2014-04-17 End Of Life 2019-04
> precise  12.04 LTS Release Date 2012-04-26 End Of Life 2017-04

Thanks, but unfortunately, I don't like Ubuntu.  Never have.  From the
first time I tested it years ago, it always rubbed me the wrong way.

B

Re: Beginning of the End for Wheezy [sigh!]

[Jonathan Dowland]

On Sun, Apr 17, 2016 at 08:30:43AM -0400, Renaud OLGIATI wrote:
> You are missing that the change to systemd makes most of the knowledge
> patiently acquired over the years running and caring for a Linux system has
> suddenly become unusable.

As a former sysadmin wrangling frankly horrid in-house init scripts,
I'll drink to that!

Re: apt cache full, mandb update failed

[Elimar Riesebieter]

* Bonno Bloksma  [2016-04-20 06:52 +]:

> Hi,
> 
[...]
> 
> My /var partition had filled up, it seems out of the 3GB there was about 
> 2.5GB in /var/cache/apt/archives.
> The solution was simple, just an apt-get autoclean, I now have 2.2GB free on 
> my /var partition. ;-)
> 
> But. What wanted apt write to that mandb and was that important? 
>   /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on device
> Was that that man page for ssh or something like that?
> 
> After cleaning up I did another apt-get upgrade but it reported nothing to do.
> So if it failed to update some files why did it complete anyhow?

Because /var/cache/man/ resides on the apt-get autocleaned /var
partition?

Sigh
Elimar
-- 
  Alles was viel bedacht wird ist bedenklich!;-)
 Friedrich Nietzsche

Re: apt cache full, mandb update failed

[Dan Ritter]

On Wed, Apr 20, 2016 at 06:52:22AM +, Bonno Bloksma wrote:
> Hi,
> 
> This morning I wanted to do an apt-get update / upgrade cycle on my system.
> The update went ok, but during the upgrade I got a " No space left on device" 
> warning.
> [...]
> Preparing to replace ssh 1:6.0p1-4+deb7u3 (using 
> .../ssh_1%3a6.0p1-4+deb7u4_all.deb) ...
> Unpacking replacement ssh ...
> Processing triggers for man-db ...
> /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on device



The good news is that anything in a directory named cache should be a
temporary (but long lived) file that can be regenerated if it
needs to be.

In a tmp directory, on the other hand, you should assume that any file
can be deleted arbitrarily.

And in a spool directory, you should assume that files need to remain
there until their purpose is complete.

Jessie- iwl3945: could not read microcode: -12 (solved)

[Vladimir D.]

Hi All,
I had exactly the same problem as described by Markos.
Solution for me was to select in Grub "Advanced Options for Debian" and simply 
chose first option which in my case was "Debian .. with Linux 3.16.0-4-686-pae" 
and by selecting this it notified about missing firmware but didn't get stuck 
in that screen and followed with logging screen. I don't know what's the 
difference but could help someone else to get over this.
My PC is Acer Aspire 5633 WLMi.
BTW that precise description at the beginning is perfect. At least i know what 
package to look for.
Only pain I came across with Jessie was to add user to sudo group as I had to 
reboot pc in "recover mode" otherwise there is no other way to add that user to 
sudo group or at least I am not aware of but this would be different issue.
Another thing as suggested on Debian website when downloading firmware for Wifi 
adding source to synaptic but that didn't work for me or I don't know how to do 
it yet.
Vlad.

Problems with vdpau

[Himanshu Shekhar]

I have no NVIDIA hardware, still there are packages that install packages
containing vdpau in their name.
Any such installation causes trouble as the CLI tty(s) (a.k.a. virtual
consoles) are not available to use as long as any library related to vdpau
are installed.

Removal of any package having vdpau in its name resolves the problem.
Is this the issue with vdpau?

System details :
Debian Stretch with GNOME.
Dell Inspiron 3543 Intel Core i5 5200 processor with integrated Intel HD
graphics only.

Regards
Himanshu Shekhar

Nvidia and Intel cards on Thinkpad: observation

[Johann Spies]

On a Thinkpad T550 I observed that when using ' optirun glxgears
-fullscreen'  the framerate is much lower than otherwise.  What would be
the explanation?

If you look at the following results the Intel-results are :

$ optirun  glxgears  -fullscreen
109 frames in 5.0 seconds = 21.666 FPS
112 frames in 5.0 seconds = 22.256 FPS
112 frames in 5.0 seconds = 22.234 FPS

$ glxgears  -fullscreen
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
303 frames in 5.0 seconds = 60.469 FPS
300 frames in 5.0 seconds = 59.961 FPS
300 frames in 5.0 seconds = 59.965 FPS

$ optirun  glxgears
293 frames in 5.0 seconds = 58.567 FPS
300 frames in 5.0 seconds = 59.964 FPS
300 frames in 5.0 seconds = 59.965 FPS

$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
303 frames in 5.0 seconds = 60.462 FPS
300 frames in 5.0 seconds = 59.966 FPS
300 frames in 5.0 seconds = 59.965 FPS

$lspci (irrellevant lines removed)
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated
Graphics (rev 09)
08:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940M] (rev a2)


Johann
-- 
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)