Re: systemd-logind memory limit

[Robin Humble via luv-main]

On Sun, May 14, 2017 at 12:24:21PM +1000, Russell Coker via luv-main wrote:
>When you use systemd the systemd-logind creates a new cgroup named 
>user-$UID.slice.
>...
>I've set the max_usage_in_bytes to 100M (see the above Red Hat URL for an 
>explanation of this).  But it doesn't seem to work, I've written a test 
>program that allocates memory and sets it via memset() and it gets to the 
>ulimit setting without being stopped by the cgroup limit.

you want to set one or both of these ->
 memory.limit_in_bytes
 memory.memsw.limit_in_bytes

max_usage_in_bytes just shows you the max that's been used in the
cgroup so far. not sure why it's writeable.

>The next problem of course will be having systemd-logind set the limit when it 
>creates the cgroup.  Any suggestions on that will be appreciated.

presumably
  https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html
but I haven't tried to do it yet.

in centos6 I use pam_exec.so to run a cgroup modification script. eg.
 $ tail -1 /etc/pam.d/sshd
sessionrequired pam_exec.so /opt/root/pam_user_cgroup

where pam_user_group is a simple script that finds the right cgroup
path and sets cpuset and mem limits. it uses env variables like
PAM_USER and PPID to accomplish this.

I expect this approach will still work with centos7, and perhaps could
even be applied to login pam instead of ssh, but it may not be the most
elegant solution ot the best integrated with systemd.

I'd be interested in what you come up with.

cheers,
robin
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: Resizing jpegs, limiting file size

[Craig Sanders via luv-main]

On Sun, May 14, 2017 at 07:02:41PM +1000, Tony White wrote:

> #!/bin/sh
> # run this is script in the image folder
> # change the value 320 to whatever width you want
> response = 320
> for f in *; do
> # prefix the results with sm_ or change to what you want
> convert $f -resize $response +profile "*" sm_$f
> done

You really should quote your variables.

If any of the filenames have spaces (or other problematic characters
like *, ?, [, (, and other characters with special meaning to the
shell) in them, this script will break.

Those are all valid characters in a filename on all linux
filesystems. There are only two characters which are not valid in a
filename, a forward-slash and a NUL byte.  Anything else is permitted.

To avoid any problems cause by such annoying characters, you should
surround variables names with double-quotes when you use them, for the
same reason you quoted the "*". e.g.

convert "$f" -resize "$response" +profile "*" "sm_$f"

There are other reasons to quote variables, especially when you can not
have complete knowledge or control over the value of a variable.

As a general rule, **ALWAYS** double-quote variables when you use them.
It can pretty nearly never hurt to double-quote a variable, but there
are plenty of situations using an unquoted variable can cause severe
damage.

(NOTE: there are some very specific rare situations where you don't want
to and shouldn't quote variables, but if you´re capable of writing
the kind of shell code that requires that, you'll know when not to
quote. Otherwise, just quote variables all the time: 99 times out
of 100 (or more) it is exactly the right, safe, and correct thing
to do. Or, to put it another way, unless you know exactly WHY you don't
want to quote a specific variable, then quote it)

BTW, this script has clearly not been tested - typed in from memory?
There should be no space between the variable name, the equals sign, or
the value being assigned. ´response=320' would assign the value 320 to
the variable $response. 'response = 320' does not, it is an attempt to
run a command called 'response' with two command line arguments '=' and
'320'.

Also BTW, use double-quotes when you need to interpolate variables or
sub-shell results etc into a string, and it's best to use single-quotes
otherwise, like so:

convert "$f" -resize "$response" +profile '*' "sm_$f"

That's the key difference between double and single-quotes - single-quotes
are for static, fixed, literal strings.  Double-quotes are for for variables
and other dynamically generated output.

Finally, when passing filename arguments to programs that understand the
GNU convention of '--' to indicate the end of program options, it's also
always a good idea to use it to prevent filenames beginning with a '-'
from being interpreted as options. e.g. if a directory contains a file
called '-rf' in it, there is a huge difference between running 'rm *'
and 'rm -- *'


craig

--
craig sanders 
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main