Wed, 19.04.17 15:25, Samuel Williams (space.ship.travel...@gmail.com)
> wrote:
>
>> I am using MariaDB - and the .service file launches mysqld directly -
>> it doesn't use mysqld_safe
>>
>> Here is the basic config, from Arch linux package:
>>
>> -
I am using MariaDB - and the .service file launches mysqld directly -
it doesn't use mysqld_safe
Here is the basic config, from Arch linux package:
-- mariadb.service
ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER
$_WSREP_START_POSITION
ExecStartPost=/bin/sh -c "systemctl unset-envir
Also, it was me sending SIGKILL, not systemctl. systemctl sent SIGTERM
and then finished. But process is still running, so system ended up in
weird state.
On 19 April 2017 at 15:25, Samuel Williams
wrote:
> I am using MariaDB - and the .service file launches mysqld directly -
> it doesn
I had an accident last night. I tried to delete a lot of rows from a
production database in one transaction. I killed the transaction, and
I didn't realise it was still rolling back an hour later when I tried
to reboot the system for updates.
I might be wrong about exactly who is doing what, but I
2016 at 15:36, Samuel Williams
wrote:
> Okay, so tried some more things.
>
> $ sudo su - http env
> This account is currently not available.
>
> That's because the user has nologin set as the shell.
>
> So, does that mean it's impossible to use systemctl --user
Okay, so tried some more things.
$ sudo su - http env
This account is currently not available.
That's because the user has nologin set as the shell.
So, does that mean it's impossible to use systemctl --user ?
On 14 December 2016 at 13:13, Samuel Williams
wrote:
> Its unfortu
Its unfortunately common for popular software to have CVEs, it's a sign of
an overall healthy environment I think. In any case my original point still
stands, regarding formal verification. But that's not the main issue here
so let's not get sidetracked :)
__
> Well, given I opened the PR, I'd hope the chance is very low -- at least, no
> more than sudo.
Sudo verifies the configuration using a regular language. It doesn't
mean you can't shoot yourself in the foot, but it makes it pretty damn
hard. JavaScript on the other hand.. a logic bug or error in
So, I was playing around with sudo and found the following:
% env | grep XDG
XDG_SESSION_ID=4
XDG_RUNTIME_DIR=/run/user/1000
% sudo -u http env | grep XDG
... nothing...
Found this:
http://stackoverflow.com/questions/28809235/how-to-get-xdg-variables-with-sudo
Of course, using a login shell i
> Putting aside the issue of having users link their own units into the system
> configuration -- as pointed out else in this thread, that comes with a *lot*
> of security issues -- you don't even need sudo or su to allow users to
> control system units.
You are absolutely correct. The users ha
Reindl, thanks for your continued help.
> what *exact* problem are you trying to solve - don#t come with the solution
> "doing that as systemd-unit" - explain the problem what you are trying to
> solve not the solution you think is good!
Okay, our website deployment process is something like this
Reindl, I understand where you are coming from, but I'm not sure I
understand what the alternative you are proposing is, are you
suggesting I use su?
On 14 December 2016 at 10:45, Reindl Harald wrote:
>
>
> Am 13.12.2016 um 22:40 schrieb Samuel Williams:
>>
>> Rei
Reindl, thanks for your ideas.
So, I log in as me "bob", but I want to run a task as http, e.g. sudo
-u http git checkout -f
What do you propose as the alternative?
On 14 December 2016 at 09:49, Reindl Harald wrote:
>
>
> Am 13.12.2016 um 21:41 schrieb Samuel Williams:
&g
I wanted to use systemd --user but had trouble getting it to run via sudo-
seemed like the environment wasn't getting set up correctly. Any ideas?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/lis
I will explore using link further. However, in some cases the
behaviour is hard to leverage.
I'm using foreman to generate systemd files. If I remove an existing
target, it will be hard to replicate this.. unless I trash everything
before re-linking everything. It's not a very elegant solution.
__
Before I got to bed. It seems like it would make the most sense for me
to be able to namespace unit files. e.g. make a directory such as
/etc/systemd/system/http and give that directory suitable permissions.
Then, it's simpler to blow away all targets/services in that directory
if I need to rewrite
Hmm, so my local units directory contains business_development.target
which contains
Wants=business_development-resque-worker-high-priority.target
business_development-resque-worker.target
But when using systemctl link, neither of these get installed
correctly (and no warning is given when runnin
Thanks Andrei, this is something I will explore. Will this work well
if I have targets which have multiple dependencies? i.e. can I just
link the top level target?
On 14 December 2016 at 01:36, Andrei Borzenkov wrote:
> On Tue, Dec 13, 2016 at 3:23 PM, Samuel Williams
> wrote:
>>
I'd like my http user to be able to install unit files and start/stop them.
Starting and stopping them is fairly easy with a sudo rule..
But adding them is a bit trickier. I could also use sudo but it seems
fairly specific.
Is there some way to add a new directory, e.g.
/etc/systemd/system/http
I want to use this field for a list of roles the server will be setup
with. It feels like a logical thing to do. But for some reason, the
field is very limited:
# hostnamectl set-deployment "roles:development roles:business"
Could not set property: Invalid deployment 'roles:development roles:busin
tails
(e.g. stopping and starting the remote machine) that it would be nice to
keep it easy for new users.
On 13 October 2016 at 02:10, Chris Bell wrote:
> On 2016-10-11 22:29, Samuel Williams wrote:
>
>>
>> For step 2, what would be the best practice. Rsync the local containe
Hello.
I've been thinking about how I could use systemd-nspawn containers.
Ideally, we have a local container which can then be pushed to one or more
VPS instances.
An example workflow might look like this:
- Step 1: On development box, update some software in a container and test.
It's okay.
-
t I suspect there is
more than just one person with this issue.
On 12 April 2016 at 02:21, Lennart Poettering wrote:
> On Sun, 10.04.16 22:57, Samuel Williams (space.ship.travel...@gmail.com)
> wrote:
>
> > Hello,
> >
> >
> > I've been trying to figure out the b
I would like to write to /dev/stderr and tried that but it didn’t work. I think
it’s something to do with the way it works internally (nginx + phusion
passenger).
> On 11/04/2016, at 12:43 AM, Mantas Mikulėnas wrote:
>
> On Sun, Apr 10, 2016 at 1:57 PM, Samuel
Hello,
I've been trying to figure out the best way to support legacy applications
that don't support syslog for logging. The best we can do, I think, is to
use fifo and have another process read the fifo to journald.
I made the following unit journald-fifo@.service
[Unit]
Description=A fifo
25 matches
Mail list logo
